[00:00] <veebers> lol, sorry that was a bit of a CnP fumble
[00:00] <waigani> hehe, np. what does `juju debug-log` give you?
[00:00] <waigani> anything jump out?
[00:01] <waigani> also, what logs do you have in ~/.juju/local/log ?
[00:01] <waigani> there should be an all-machines.log and a log for just the machine
[00:01] <veebers> In that dir I have all-machines.log and machine-0.log,
[00:02] <veebers> I don't see a log for the local unit (probably as it fails to even start)
[00:02] <waigani> great. time get grepping
[00:03] <waigani> veebers: wait, did you say you started up the templates?
[00:03] <waigani> veebers: they should be stopped
[00:04] <waigani> veebers: new containers are cloned from them - but they can't be running
[00:04] <veebers> waigani: aye, I started than stopped it, Just wanted to make sure it ran. The template image starts up fine, the local unit does not
[00:05] <waigani> veebers: okay. template was stopped when you deployed the ubunut service though?
[00:05] <veebers> waigani: so this is what I hve in my environment.yaml under local: http://pastebin.ubuntu.com/11956665/
[00:06] <waigani> veebers: could you dump the logs somewhere I can take a look at them?
[00:07] <veebers> waigani: can do, let me make sure I'm not posting secret/private [arts
[00:08] <waigani> veebers: this looks like you: https://bugs.launchpad.net/juju-core/+bug/1364939
[00:08] <mup> Bug #1364939: container failed to start with lxc-clone-aufs=true <config> <deploy> <local-provider> <lxc> <regression> <juju-core:Fix Released by alesstimec> <https://launchpad.net/bugs/1364939>
[00:09] <waigani> fix released in 1.21
[00:10] <veebers> waigani: hmm interesting, so either I need to go to 1.21 or perhaps just remove that from my config?
[00:11] <waigani> veebers: yeah, I'd say so. Go to 1.21 if you can.
[00:12] <veebers> waigani: which would mean a distro upgrade right? Not avaiable on utopic?
[00:15] <waigani> veebers: you can add a ppa: ppa:juju/stable
[00:15] <veebers> waigani: ah, no way :-) sweet, I'll give that a hoon and see how it goes
[00:15] <veebers> cheers waigani, if this works out I'll owe you a beer or 2
[00:15] <waigani> veebers: code craft is coming up.... ;)
[00:16] <veebers> waigani: ^_^
[00:18] <waigani> veebers: when testing a particular version I usually grab it from here: https://github.com/juju/juju/releases, run `make install` and I'm good to go. But the ppa is the standard way.
[00:20] <veebers> waigani: heh, I only want something that works, not the bleeding edge ;-)
[00:20] <waigani> veebers: fair enough - isn't that what we all want?
[00:21] <veebers> ^_^
[02:11] <aisrael> jose: pong
[02:12] <jose> aisrael: I'm checking that you referenced an MP but as a bug here https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/add-rsync-timeout/+merge/261424
[02:12] <jose> and now I can't find the MP
[02:12] <jose> do you by chance remember what it was?
[02:17] <aisrael> I think this was one of them: https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/fix_cron_path/+merge/260696
[02:18] <aisrael> and this might have been the other: https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/update_charm-helpers/+merge/260956
[02:25] <jose> oh, ok, thanks
[02:26] <veebers> waigani: ah you lucked out, I had another problem but I solved it myself ;-)
[02:27] <veebers> had to kill the old juju agents as it was blocking my bootstrap attempts
[02:34] <aisrael> veebers: waigani: That looks a lot like a race condition I reported last week.
[02:35] <aisrael> or the one I'm tracking down right now
[02:35] <aisrael> are you seeing it with a current version of juju?
[02:36] <veebers> aisrael: which issue is that? Having to stop the agents? If so that'll be because my juju install was screwy and I just added the stable ppa and updated
[02:37] <aisrael> veebers: ack, just reading through my scrollback.
[02:37] <aisrael> good to hear it's fixed for you!
[02:38] <veebers> Well, I'm getting further now at any rate :-)
[09:48] <rbasak> marcoceppi: sorry I haven't had a chance to look deeper into charm-tools yet. I'm running out of time as I need to finish some things up before next week's server team sprint.
[09:49] <rbasak> marcoceppi: debian/copyright needs adding, and debian/changelog updating to match the archive rather than the PPA.
[09:49] <rbasak> marcoceppi: I'd like to look into why the .postinst is required.
[09:49] <rbasak> marcoceppi: nothing else leapt out to me. Nothing major that I could see on a quick glance.
[09:50] <rbasak> marcoceppi: do you want to start a packaging branch somewhere to start fixing that up?
[12:07] <marcoceppi> rbasak: yeah, what do I need to do to start a packaging branch?
[12:07] <marcoceppi> I've got the changelog without ppa stuff already
[12:07] <rbasak> marcoceppi: easiest to have a branch that adds the debian directory with all its contents
[12:08] <rbasak> So then the debian directory can evolve independently of "upstream" as packaging fixes are made
[14:24] <gnuoy> jamespage, beisner, so, I missed that the section names passed by the subordinate to the principle may not match (as is the case with nova-omcpute) so I have an additional mp for fixing Bug #1478061
[14:24] <mup> Bug #1478061: subordinate config data is being dropped for nova.conf <amulet> <openstack> <uosci> <nova-compute (Juju Charms Collection):Triaged by gnuoy> <https://launchpad.net/bugs/1478061>
[14:25] <gnuoy> https://code.launchpad.net/~gnuoy/charm-helpers/subconfs-multi-sections/+merge/266237
[15:39] <beisner> gnuoy, do you have the proposed c-h fixes syncd into a nova-compute branch somewhere?  if so, I can cycle that through tests.  ta!
[15:51] <jamespage> gnuoy, +1 on that fix
[15:52] <gnuoy> jamespage, thanks
[16:11] <gnuoy> beisner, I'm hoping lp:~gnuoy/charms/trusty/nova-compute/subctxt-fix will fix it
[16:15] <beisner> gnuoy, ok hmm, just realized that i don't have an easy way to tell the amulet test to deploy *that* n-c charm, in the ceilometer-agent tests.  it will pull n-c from next/stable.
[16:15] <gnuoy> yep
[16:15] <beisner> gnuoy, perhaps the n-c amulet test should incorporate subordinates in its tests anyway.
[16:15] <gnuoy> beisner, I have a mp up my sleeve from that but I'm not going to propose it in the next few days
[16:16] <gnuoy> s/from that/for specifying alternative branches in amulet tests/
[16:38] <beisner> gnuoy, ah yes very good.  i've also put some thought into how to approach that, but no WIP yet.
[17:26] <beisner> gnuoy, heads up, i'll have a batch of MPs for next charms re: amulet test cleanup before the push.  things like removing utopic, a few cleanup items on the qg rename.
[18:40] <beisner> gnuoy, wolsen, jamespage -  3 oopsie-MPs to expedite if you will, necessary for final checks before the 1507 push:
[18:41] <beisner> https://code.launchpad.net/~1chb1n/charms/trusty/neutron-gateway/next1507-amulet-cleanup/+merge/266289
[18:41] <beisner> https://code.launchpad.net/~1chb1n/charms/trusty/neutron-api/next1507-amulet-cleanup/+merge/266279
[18:41] <beisner> https://code.launchpad.net/~1chb1n/charms/trusty/hacluster/next1507-amulet-cleanup/+merge/266298
[18:46] <wolsen> beisner, looking
[18:47] <beisner> wolsen, much appreciated
[18:48] <beisner> wolsen, wolsen, i also have an MP for the remainder of the next charms, just removing the unsupported test.  will be easier to remove now, than to remove twice after 1507 lands.
[18:48] <beisner> wolsen, but the others don't functionally impact the tests like those 3 could ^
[18:48] <wolsen> beisner, completely agree ... these look to remove the utopic tests
[18:49] <wolsen> beisner, I'd have to look again, but trusty-juno is exercised still? e.g. we don't lose juno from here do we?
[18:49]  * wolsen looks at code
[18:49] <beisner> wolsen, should just be --utopic
[18:50] <wolsen> beisner, that's what i understood as well
[18:50] <beisner> wolsen, it's a bashtastic sanity checker that i can now iterate over next charms to ID red flags like these.   so going forward, it'll be something we can do periodically.
[18:53] <wolsen> beisner, I have a feeling that stable=True/False flag might fail to get updated somewhere between /next and /trunk
[18:53] <wolsen> ;)
[18:53] <beisner> wolsen, fwiw (shhh.  i've had utopic-juno blacklisted / not-run since it EOL'd last week.)
[18:53] <wolsen> heh
[18:53] <beisner> wolsen, yep it's on our post-release checklist
[18:54] <beisner> wolsen, i have a batch for that.
[18:54] <wolsen> sweet
[18:54] <beisner> wolsen, you may very well get to merge those ;-)   coreycb, my usual merger for such things, is relaxing on a well deserved vaca somewhere.
[18:55] <wolsen> beisner, that's cool - just let me know
[18:55] <beisner> wolsen, thx man
[18:57] <beisner> wolsen, fyi  along the same lines as that stable true/false thing, is flipping the branch to the stable charmhelpers in charm-helpers.yaml  after we push the charms to stable.
[18:58] <wolsen> beisner, yep yep
[18:58] <wolsen> beisner, oy wish the quantum-gateway to neutron-gateway had been caught in the neturon-api a bit earlier
[18:58] <beisner> wolsen, and that bit has historically been gnuoy ;-)  but i could add that to the same pass that does the other post-push thingy.
[18:58] <beisner> wolsen, yeah.
[18:59] <beisner> wolsen, oy.  i really wanna hammer the whole set of amulet tests on all next charms again once that lands.
[18:59] <beisner> wolsen, we don't have a good way to consume my proposed branch in each of the affected tests.  they all pull the next charm.
[18:59] <wolsen> beisner, can you also add to your checklist that all branches should be tagged release version?  gnuoy did it last time for the 15.04 on the /next branch - which was great, but we need it on the /trunk as well
[19:00] <beisner> wolsen, yep - added to list  ;-)
[19:00] <wolsen> beisner, thx
[19:07] <bhundven> what is the difference between the launchpad and github versions of juju?
[19:07] <wolsen> beisner, done
[19:08] <wolsen> beisner, thanks for making them fairly trivial :)
[19:09] <beisner> wolsen, thanks a ton!
[19:15] <bhundven> or is the github version supposed to be a mirror of the launchpad code?
[19:17] <bhundven> nevermind ;)
[19:17] <Makyo> Trying to deploy juju-gui to any environment, I get "ERROR invalid character 'o' looking for beginning of value" juju 1.24.2-utopic-amd64.  This has been an issue for a few months now.  Any clues?
[19:28] <beisner> wolsen, bored yet?  here's a pile o' trivials:  http://paste.ubuntu.com/11961606/
[20:17] <wolsen> beisner, I'll queue em up for this afternoon
[22:03] <beisner> wolsen, jamespage, gnuoy - spinning as much through metal as i can;  no virtual testing per priv channel msg re: errors.
[22:03]  * beisner goes to eat while disks grind