[08:27] <gnuoy> I'm using add-machine to precreate some machines that need some configuration before adding services to them. I'd like to use juju-deployer to do the service deployment and one of the services needs multiple units. I thought
[08:27] <gnuoy>     num_units: 3
[08:27] <gnuoy>     to: [3, 4, 5]
[08:28] <gnuoy> was what was needed but that results in http://paste.ubuntu.com/7882698/
[08:28] <gnuoy> and ideas?
[11:19] <jamespage> marcoceppi, morning - I have an amulet question for you
[11:19] <jamespage> marcoceppi, how does sentry.wait() determine that all hooks have finished executing? I'm seeing a race in the openstack tests we are writing - hooks are def still firing post .wait() completing
[12:26] <marcoceppi>  jamespage it infers if a unit is ready by checking for any jujud processes running hooks/*
[12:26] <marcoceppi> does a round robin check of all of the units
[12:34] <sante> Hi all, I just setup a juju environment in an openstack cloud. If I set the environment on the precise release everything goes well. If I leave the default series unconfigured every deploy involving a trusty image get stuck and does not work at all. Can anyone help me debugging this problem?
[12:44] <Beret> t
[13:09] <jamespage> marcoceppi, so its possible it could false positive?
[13:10] <marcoceppi> jamespage: I mean, it's possible. I thought I had resolved that, but in large deployments it's fesable that you could get a false positive
[13:10] <marcoceppi> jamespage: I'll look in to better detection by investigating the event queue directly in juju rather than trying to query each unit individually
[13:18] <Egoist_> Hello
[13:18] <Egoist_> I have made few changes in charms, and want to put it on to the charm store?
[13:18] <Egoist_> Is it possible to do that?
[13:21] <jamespage> Egoist_, indeed it is - just proposed your changes against the branches on launchpad
[13:24] <Egoist_> jamespage, can you explain to me how to do it?
[13:25] <jamespage> Egoist_, https://juju.ubuntu.com/docs/authors-charm-store.html
[14:17] <natefinch> irc on a tablet is rather suboptimal
[14:23] <TheMue> natefinch: at least an alternative to the non-networking notebook
[14:24] <natefinch> indeed
[14:25] <TheMue> natefinch: from time to time I’m using my pad too, for quick jumps into the net
[15:39] <avoine> lazyPower: my python-django MP is ready for an other review:
[15:39] <avoine> https://code.launchpad.net/~patrick-hetu/charms/precise/python-django/pure-python/+merge/226742
[15:40] <lazyPower> bcsaller: will you have a chance to look over that MP today? ^ We had some concerns about it last week.
[15:40] <lazyPower> avoine: ty for the follow up ping. I'm a bit slammed but will get to it no later than wednesday if bcsaller doesn't get to it first.
[15:41] <avoine> lazyPower: also I'll write a mail on the mailling list to explain my experience/problems with the Ansible migration
[15:41] <avoine> lazyPower: ok thanks
[15:44] <lazyPower> thanks for the follow up as well. That will be great feedback to have
[22:07] <ctlaugh> jamespage: mwhudson mentioned I should ask you about the cinder juju charm.  It is having a problem deploying on a host with a single drive.  I am using the configuration option "disk.img|sizeG" because the system I am installing on does not have an sdb. For a while, I was seeing that it wasn't creating the loopback device, but now it seems to be doing it all the time.  What isn't happening is creating the volume group.  I'm running
[22:07] <ctlaugh> trusty.  Do you know where I should look to try to figure out why?
[23:33] <noodles775> lazyPower: Anyone I can ping to get reviews for these elasticsearch charm updates from 3 weeks ago? (Adds firewall rules for the 9200/9300 ports): https://code.launchpad.net/~michael.nelson/charms/trusty/elasticsearch/add-ufw/+merge/225934 https://code.launchpad.net/~michael.nelson/charms/trusty/elasticsearch/ufw-for-peers-too/+merge/225968
[23:34] <lazyPower> noodles775: bcsaller is on review this week.
[23:37] <noodles775> lazyPower: great, txs
[23:40] <noodles775> lazyPower: just a thought, but I wonder if the review velocity would be a lot greater if people actually involved with the charm (who are also charmers) reviewed them (ie. they have context), rather than one person (on rotation) having to get context for each and every charm.
[23:41] <noodles775> I mean, hazmat (who has not only context, but an interest in the charm) could probably review my two in 5mins each without needing any extra context (but I know how busy he is), as opposed to someone else who may need 0.5hr per MP.
[23:42] <sebas5384> jcastro: ping
[23:43] <sarnold> noodles775: there's also value in spreading around knowledge inside a team :)
[23:45] <noodles775> sarnold: yes, that's also valuable of course, but I don't think it's worth an average 4 week wait time for updates to charms. I think that same knowlege can be spread more effectively by examining other charms of interest.
[23:47] <sarnold> noodles775: don't forget, these guys are The New Hotness :) investing in their knowledge rotation will pay dividends down the road
[23:50] <hazmat> noodles775, looking
[23:51] <noodles775> Thanks hazmat
[23:54] <hazmat> noodles775, what happens on upgrade?
[23:55] <hazmat> afaics it setups ufw in deny mode then, and extant clients are hosed
[23:57] <noodles775> hazmat: I'll test and fix it with a paste of the output on the MP. Txs (I'd only tested deploy).
[23:57] <noodles775> sarnold: yep, I'm all for us investing in each others knowledge of other charms and strategies for charms.
[23:58] <hazmat> noodles775, added comment
[23:58] <hazmat> to mp