[01:52] <hazmat> blr: no.. if you want to manually configure containers, you can use the manual provider
[01:53] <blr> hazmat: aware the correct thing to do is charm the other dependant service and set the IP with a relation, but the other service is super non-trivial to charm
[01:54] <blr> will have a look at the manual provider though, thanks
[10:15] <Muntaner> hi guys
[10:15] <Muntaner> how can I detach a public address (floating IP) to a juju service?
[10:24] <Muntaner> marcoceppi, I'm adapting my charm to load balancing. Have you got any suggestion? Can I simply follow the WordPress charm code?
[10:49] <Muntaner> frankban, I detached a floating IP to a Juju VM; but Juju GUI isn't updating (still diplays the floating ip)
[10:51] <frankban> Muntaner: where is the ip displayed in the GUI? how did you detach the floating ip?
[10:52] <Muntaner> frankban, I detached it via OpenStack Horizon dashboard. I still can see the old IP by clicking on the charm, clicking on the mysql/0 - ish on the left
[10:53] <frankban> Muntaner: do you see the old ip with juju status?
[10:54] <Muntaner> frankban, this can sound strange - I tried to do that with mysql and haproxy. On mysql charm the status does not show the old IP, while for haproxy I still see the old one
[10:55] <Muntaner> in the GUI, I see the old IP from both of them
[10:55] <Muntaner> frankban, juju does not have a mechanism to detach the IPs?
[11:01] <frankban> Muntaner: not sure about the how juju reacts to this kind of changes directly done by using horizon. Perhaps you can get help from someone more expert of openstack stuff. Since openstack environments have a use-floating-ip option, I guess you can run "juju environment set" to enable or disable floating ips, but never tryed
[11:01] <frankban> tried even
[11:08] <Muntaner> frankban, ty
[11:27] <bloodearnest> heya all. Am trying to write amulet test for apache, but it keeps using the wrong charm
[11:27] <bloodearnest> I do:
[11:27] <bloodearnest> d = amulet.Deployment(series='trusty')
[11:27] <bloodearnest> d.add('apache2')
[11:27] <bloodearnest> but I get the current cs version, not my local version on disk
[11:47] <Muntaner> marcoceppi, have you got a few minutes?
[11:53] <stub> bloodearnest: The second argument to d.add is the path to the charm, which avoids the problem
[11:55] <bloodearnest> stub, lovely, thanks
[12:46] <rbasak> frankban: what is juju-quickstart 2.0's compatibility with older versions of Juju, please?
[12:47] <frankban> rbasak: no changes from previous versions, so it supports juju >= 1.18.
[12:47] <rbasak> frankban: OK. Thanks!
[12:47] <frankban> rbasak: there is an open bug we are working on FYI and I we expect to release a 2.0.1 today or tomorrow.
[12:49] <rbasak> ack. I can work on the packaging anyway, since that'll presumably be a minor change I can pull in before upload.
[13:02] <frankban> rbasak: +1
[13:19] <skay> hi all, I haven't run bundletester before. I need help https://code.launchpad.net/~codersquid/charms/trusty/python-django/pip-extra-args/+merge/245785
[13:19] <skay> not urgently, but if you have a chance, please take a look and comment
[13:20] <skay> also, would it be possible to unpin bundletester's dep on bzr and make it >= ?
[14:09] <nicopace> hi whit, marcoceppi, asanjar, jcastro, arosales. A new week begins, and i return with my review requests :) This is a reminder: https://code.launchpad.net/~nicopace/+activereviews There are still 9 pending branches
[15:06] <Muntaner> good mornign guys
[15:18] <Muntaner> marcoceppi, toc toc
[15:31] <tvansteenburgh> skay: fwiw, i branched python-django/trunk and ran `bundletester -e amazon -l DEBUG -v` and all the tests passed (using latest bundletester from github)
[15:35] <skay> tvansteenburgh: thanks, I'll try that.
[16:00] <Muntaner> I am deploying a haproxy charm, and trying to connect to it, but nobody seems to happen
[17:34] <bloodearnest> stub, adding path as a second arg to add() doesn't seem to work for me - I still need to have JUJU_REPOSITORY set for it work
[17:37] <bdx> I have a few questions regarding charm configuration is there someone who might have an extra minute or two to advise me of a best practice?
[17:38] <bdx> jamespage: Could you have a look at this https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/456 ?
[17:40] <bdx> charmers: Can anyone give any insight here https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/456 ?
[17:57] <bdx> Any takers https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/456 ?
[18:05] <whit> anyone have any good ideas for the dockercon hackathon?
[18:05]  * whit means other than marcoceppi idea to go do something cool in lxc and then reveal it at the last moment
[18:44] <bdx> jamespage, charmers: If a charm, say cinder is deployed, and the configs os-admin-network, os-internal-network, and os-public-network are respectivly 10.50.0.0/24, 10.60.0.0/24 and 10.70.0.0/24, must then the physical node that the cinder charm is deployed to be connected on all three seperate networks?
[19:28] <jorge> marcoceppi, can you link to your actions blog post?
[19:28] <marcoceppi> jorge: when I finish writing it
[19:28] <jorge> oh lol
[19:54] <jamespage> bdx, indeed it must be
[19:55] <jamespage> otherwise the charm will just fallback to private-address from juju
[20:09] <mchasal> marcoceppi, jorge I wonder if you could help with some project organization issues we're having. We've got a single project that is housing multiple charms. We've got a devel branch where we've been doing our work, but I'm having trouble figuring out how to handle publishing this to the charm store since they will be on different schedules. Can't just merge the whole devel branch with trunk as it will pull in charms that aren't ready.
[20:09] <mchasal> Here's the project page: https://launchpad.net/ibmcharms
[20:09] <jcastro> hi
[20:09] <mchasal> Any advice?
[20:10] <marcoceppi> soo/
[20:10] <marcoceppi> o/ *
[20:10] <jcastro> when you mean publishing to the charm store
[20:11] <jcastro> do you mean like just having everything in this lp project indexed on jujucharms.com?
[20:11] <mchasal> Yes, and, and so users can eventually just deploy from there.
[20:13] <mchasal> My understanding is that Launchpad will automatically find any charms pushed to a trunk branch.
[20:13] <jcastro> yeah
[20:13] <jcastro> you need to put /charms/ in the branch name though
[20:13] <mchasal> Ah, ok, not just in the path.
[20:13] <jcastro> so like I see in your branches you have like
[20:13] <jcastro> ~username/ibmcharms/kimchi
[20:14] <jcastro> you can push to ~username/ibmcharms/charms/trusty/kimchi for example
[20:14] <jcastro> mchasal, but that's just how it is now
[20:14] <jcastro> soon you can push to wherever you want, then just `juju publish`
[20:15] <mchasal> Yes, I understand those changes are coming.
[20:15]  * jcastro nods
[20:15] <mchasal> I think we're going to be pushing our first versions of these soon though, I'm guessing before publish is out there.
[20:15] <jcastro> yeah
[20:16] <jcastro> from there after you push I believe the threshold is 15 minutes for it to get listed
[20:17] <mchasal> Ok, that's no problem. I'm just trying to get this project structured in a sensible way, which I don't think I did the first time around.
[20:17] <mchasal> Trying to keep all the charms we're working on under this single umbrella.
[20:18] <mchasal> But it looks like a single devel branch was too much.
[20:18] <jcastro> yeah
[20:18] <jcastro> also remember you need a place for the bundles too
[20:22] <mchasal> I guess I'm still a little confused about the series, in your example above: "push ~username/ibmcharms/charms/trusty/kimchi" That's just going to go to whatever the development focus series is.
[20:24] <jcastro> series is just linked to the distro though
[20:24] <jcastro> wherever trunk development of the charm is can be anywhere
[20:25] <jcastro> let me try to find how the openstack charmers do it
[20:25] <mchasal> Hmm, maybe I'm mixing up my terminology.
[20:25] <jcastro> they have a nice setup for devel and then propagating that to release
[20:25] <mchasal> I was looking at their repos trying to understand this.
[20:25] <jcastro> you want one place to do devel, and you want one place that is stable right?
[20:26] <mchasal> right, I just don't want the automated process to pick stuff up before it's ready to be published. I was trying to encourage our members to push code regularly.
[20:27] <mchasal> So yes, trunk/stable and devel
[20:28] <jcastro> marcoceppi, do you have any insight into how the openstack guys do this?
[20:28] <jcastro> I am noticing milestones, etc. in launchpad for their charms
[20:29] <mchasal> Things like this confused me there too: "Merged branch lp:~hopem/charms/trusty/keystone/stable-precise-1423513"
[20:29] <mchasal> So the branch with trust in its name has stuff for Precise.
[20:29] <jcastro> hmm, I wonder if I can just ask them team to write up their whole workflow
[20:31] <mchasal> That might be a good thing.
[20:32] <jcastro> ok I'll go ahead and ask them to do so
[20:33] <mchasal> COol
[20:34] <jcastro> mchasal, aha!
[20:34] <jcastro> https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/
[20:34] <jcastro> looks like they did that already, see the "development flow" section
[20:34] <mchasal> You mean they didn't just write that now?
[20:35] <jcastro> heh
[20:35] <jcastro> I'll go ahead and post this to the list too
[20:36] <jcastro> I think I'll put this in best practices as well
[20:39] <mchasal> Thanks for the help, I'll have to try and digest this all now.
[20:39] <mchasal> It's still not clear to me where the trunk branch fits in.
[20:40] <jcastro> Yeah, the reason I posted to the list was that if you had questions you can respond, because james is in the uk and will hopefully answer it before you start your day tomorrow
[20:41] <mchasal> Ok, I'll keep an eye on it.
[23:38] <sebas5384> lazyPower: ping
[23:54] <lazyPower> sebas5384: pong
[23:54] <sebas5384> lazyPower: hey!
[23:55] <lazyPower> whats up?
[23:55] <sebas5384> we have a team here that are starting to using docker + ansible
[23:55] <sebas5384> and the discussion of juju vs docker came up
[23:56] <sebas5384> I understand the diference
[23:56] <lazyPower> two completely different, and somewhat complimentary technologies.
[23:56] <sebas5384> yeah I know
[23:56] <sebas5384> but
[23:57] <sebas5384> the thing that was concluded at the end of the discussion was that juju is more like if you need to install a docker cluster
[23:57] <sebas5384> to then
[23:57] <sebas5384> use docker
[23:57] <sebas5384> and orchestrate your containers with other tool like flannel (i don't know really)
[23:57] <lazyPower> sebas5384: flannel isn't an orchestration tool
[23:58] <sebas5384> hmmm what is then?
[23:58] <lazyPower> sebas5384: flannel is a software defined networking stack that compliments docker's networking bridge, so you can do L2 over L3 networking.
[23:58] <lazyPower> eg: cross host networking
[23:58] <sebas5384> hmmm get it
[23:58] <sebas5384> thanks for the explaining
[23:58] <lazyPower> sebas5384: the way i explain this to people who ask... (give me a minute to type this out)
[23:58] <sebas5384> ok
[23:58] <sebas5384> :)
[23:59] <sebas5384> till that, the issue here was like, why Juju doesn't use docker as a provider