[01:29] <thumper> stub: can you ping me when you are around, I have a (hopefully simple) postgresql question for you
[02:41] <noodles775> Can someone help me find more info about an issue I'm having: (Very) Approximately 50% of deploys I'm testing with the local provider, result in 7 of 8 machines all coming up successfully, but 1 machine remaining pending/allocating. If I check the machine log, that one machine is unable to connect to the api apparently because the juju-generated CA is rejected: http://paste.ubuntu.com/11071952/
[02:55] <noodles775> I'll create a bug after lunch and destroy the env again, but if there's anything else I can put on the bug report while it's still up, that'd be great to know.
[03:21] <thumper> noodles775: hmm... sounds bad
[03:21] <thumper> yes, bug please
[03:48] <noodles775> thumper: done (jfyi) https://bugs.launchpad.net/juju-core/+bug/1453644
[03:48] <mup> Bug #1453644: One unit remains pending with local provider <juju-core:New> <https://launchpad.net/bugs/1453644>
[04:27] <thumper> noodles775: ta
[06:09] <schkovich> good morning, is charm-helper-sh package abandoned?! if yes does anyone know why?
[06:11] <lazyPower> schkovich: its depreciated in favor of the `charmhelpers` package, which exposes a lot of the functionality through the 'ch' command
[06:11] <schkovich> thanks lazyPower :)
[06:12] <lazyPower> schkovich: however, the `ch` command is largely undocumented at this point, but marcoceppi may have published them while I wasn't looking.
[06:12] <lazyPower> them being, updated docs on how to use it :)
[06:13] <schkovich> hmhhh... but it is python package. am i on the wrong page?
[06:20] <schkovich> lazyPower: I can find only projects and packages with dash eg charm-helpers and all of those are python and not bash helpers/libraries
[06:21] <schkovich> is bash deprecated in favour of python ;)
[09:28] <g3naro> ls -lhrt
[10:45] <gnuoy> jamespage, ooi are you using juju 1.24 ? I seem to be seeing juju-dpeloyer explosions with it
[10:46] <jamespage> gnuoy, not yet
[10:46] <gnuoy> ah, ok.
[10:48] <gnuoy> mgz, do you use juju-deployer in any of your juju testing?
[10:48] <jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/neutron-api/kilo-dvr-stable/+merge/258750
[10:48] <gnuoy> jamespage, ta
[10:50] <mgz> gnuoy: yup
[10:52] <mgz> gnuoy: eg http://reports.vapour.ws/releases/2627/job/aws-deployer-bundle/attempt/314
[10:53] <gnuoy> mgz, Bug #1453760
[10:53] <mup> Bug #1453760: "u'Error': u'status for key "<unit>" not found" before adding relations when using juju 1.24 <juju-deployer:New> <https://launchpad.net/bugs/1453760>
[10:57] <mgz> gnuoy: could well be a juju bug, not clear what's triggered it though
[10:58] <gnuoy> mgz, is the # in the unit name suspicious ?
[10:58] <gnuoy>  {   u'Error': u'status for key "u#keystone/0" not found',
[10:59] <mgz> yeah, it *looks* like an interal tag has leaked out somehow
[10:59] <mgz> but I'm not sure I'm reading that correctly
[11:00] <mgz> gnuoy: see bug 1437266 for comparison
[11:00] <mup> Bug #1437266: Bootstrap node occasionally panicing with "not a valid unit name" <deploy> <destroy-machine> <destroy-service> <juju-core:Triaged> <https://launchpad.net/bugs/1437266>
[11:02] <gnuoy> mgz, ah, i think mine is probably a dupe of that one
[11:02] <mgz> well, not as written, but seems likely the cause is the same
[11:35] <gnuoy> mgz, would it be possible to get Bug #1434458 triaged ? It's alsp killing random deployments
[11:35] <mup> Bug #1434458: juju-deployer address,port split not working with ipv6 <python-jujuclient:New> <https://launchpad.net/bugs/1434458>
[11:40] <mgz> gnuoy: who have we got actually working on jujuclient?
[11:41] <mgz> gnuoy: in other words, should you or I just fix this?
[11:41] <mgz> seems like bumping the bug around won't do anything
[11:41] <gnuoy> mgz, oh, I assumed juju-core handled it.
[11:41] <gnuoy> mgz, I can prep a branch
[11:41] <mgz> I will review it
[12:58] <catbus11> Hi, I tried to deploy landscape-dense-maas bundle by dragging and dropping it to the canvas, it gives "An error occurred while deploying the bundle: <urlopen error [Errno -2] Name or service not known>". Anyone know where in my configuration might be wrong?
[12:59] <rick_h_> catbus11: atm a colocated bundle (like the landscape-dense) doesn't work but we'll have releases of the juju gui and juju quickstart that do supported the colocation in the bundle this week.
[13:00] <catbus11> rick_h_: What does colocated bundle mean?
[13:01] <catbus11> ah, services deployed in the same host? I guess?
[13:01] <rick_h_> catbus11: the services are colocated on the same machine (using lxc containers or the like)
[13:03] <catbus11> rick_h_: thanks.
[13:34] <gnuoy> wallyworld, if you're about have an environment with Bug #1451283
[13:34] <mup> Bug #1451283: deployer sometimes fails with a unit status not found error <blocker> <ci> <intermittent-failure> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1451283>
[13:34] <gnuoy> s/have/I have/
[13:36] <jcastro> hey evilnickveitch
[13:37] <evilnickveitch> jcastro, hey yourself
[13:37] <jcastro> on the getting started page
[13:37] <jcastro> I think we should get rid of the links to each provider, since they're already on the sidebar
[13:37] <jcastro> it just gives us 2 places to update each time there is a new provider
[13:38] <evilnickveitch> yes, that's a fair point
[13:38] <jcastro> I'll send a PR after I send one for dreamhost
[13:38] <gnuoy> mgz, https://code.launchpad.net/~gnuoy/python-jujuclient/ipv6/+merge/258770
[13:39] <mgz> gnuoy: looking
[13:40] <gnuoy> mgz, I haven't had much joy with test_jujuclient.py. I've done a manualy deploy with ipv4 and ipv6 but that's the extent of my testing
[13:42] <mgz> what kind of not joy?
[13:42] <mgz> hm, ipaddress module is 3.3 or later
[13:45] <gnuoy> mgz, I tried it against the openstack provider and got failures=5, errors=2 and I don't believe they're related to my branch. I assume it makes some ec2 assumptions
[13:45] <mgz> is I see
[13:46] <mgz> gnuoy: what I'd do in cases like that,
[13:46] <mgz> is writea "split port" function and just add unit tests for that
[13:47] <mgz> not worry about making the whole suite green on my machine
[13:47] <gnuoy> mgz, ok, can do
[13:48] <mgz> like, I'm pretty sure your use of re.search is wrong
[13:48] <mgz> and the following line is just .strip("[]") spelt funny
[13:51] <mgz> gnuoy: like, would your unit test pass with the input "[2001:db8::1]:80"
[13:52] <gnuoy> mgz, yes I understand.   I believe it would but I'll write the unit test to prove
[14:12] <gnuoy> mgz, mp updated
[14:13] <mgz> gnuoy: ta, looks fine, do you want pytho nits?
[14:14] <gnuoy> mgz, yes pls
[14:18] <mgz> gnuoy: done
[14:19] <gnuoy> mgz, very much appreciated, thank you
[14:20] <marcoceppi> lazyPower: it's `chlp`
[14:21] <lazyPower> ah - right.
[14:21] <lazyPower> 2am though - i'm not surprised I got it wrong.
[14:21] <mgz> thanks for just fixing. we'll need to find out what the release process is too - looks from the log like dpb1 did one
[14:24] <dpb1> andreas and I have the latest builds in a PPA.  I don't have access to push to pypi, that is just hazmat (from what I know)
[14:26] <dpb1> Same for python-jujuclient btw.  I run both on my machine all the time.
[14:27] <dpb1> https://launchpad.net/~ahasenack/+archive/ubuntu/python-jujuclient, https://launchpad.net/~ahasenack/+archive/ubuntu/juju-deployer-daily
[14:27] <mgz> dpb1: thanks!
[14:28] <hazmat> dpb1: several people have pypi access
[14:29] <hazmat> dpb1: tvansteenburgh and frankban  for example, let me know if you want it as well
[14:30] <dpb1> hazmat: tvansteenburgh is enough, IMO
[14:30]  * tvansteenburgh winces
[14:35] <gnuoy> mgz, nits crushed
[14:40] <gnuoy> hazmat, I believe I've addressed the nits, any chance you could land my branch ?
[14:41] <hazmat> gnuoy: i can't atm (on corporate network) i can merge it latter this evening, if tvansteenburgh doesn't beat me to it.
[14:41] <gnuoy> hazmat, thanks, that'd be great.
[14:46] <tvansteenburgh> gnuoy, hazmat: merged
[14:46] <gnuoy> tvansteenburgh, thanks!
[15:49] <iamfuzz> any JuJu AWS experts about?  Trying to add a custom endpoint (for eucalyptus) by modifying aws.go, but when running juju bootstrap, I get the error:  ERROR index file has no data for cloud {emea-az-1 http://109.104.120.3:8773/services/compute} not found
[15:49] <iamfuzz> what other files do I need to add the endpoint to to test this?
[15:56] <stub> aisrael: You pinged me last week
[15:57] <aisrael> stub: Hey. I was testing the postgresql charm at the time, but then you moved it to work-in-progress.
[15:58] <stub> aisrael: Yeah, I'm not sure I can get the tests running sanely without much more restructuring. I'm thinking of doing that as part of a major rewrite now I have cool new juju features to work with.
[15:58] <mwenning> lazyPower, ping
[15:58] <lazyPower> mwenning: pong
[15:59] <aisrael> stub: ack. If you need eyes on it, let me know.
[15:59] <stub> aisrael: Maybe I can get some of them back. I'll be looking at it again this week.
[15:59] <mwenning> Just got an email from Jean-Francois Joly, is everything set up for them?  any roadblocks?
[16:00] <lazyPower> mwenning: they're at the point they need review from the ~openstack team
[16:00] <lazyPower> ~openstack-charmers
[16:00] <mwenning> lazyPower, who's that
[16:00] <lazyPower> https://launchpad.net/~openstack-charmers
[16:01] <lazyPower> oi *facepalm* i saw your reply and didnt verify...
[21:49] <thumper> kirkland: ping