[00:00] lol, sorry that was a bit of a CnP fumble [00:00] hehe, np. what does `juju debug-log` give you? [00:00] anything jump out? [00:01] also, what logs do you have in ~/.juju/local/log ? [00:01] there should be an all-machines.log and a log for just the machine [00:01] In that dir I have all-machines.log and machine-0.log, [00:02] I don't see a log for the local unit (probably as it fails to even start) [00:02] great. time get grepping [00:03] veebers: wait, did you say you started up the templates? [00:03] veebers: they should be stopped [00:04] veebers: new containers are cloned from them - but they can't be running [00:04] 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] veebers: okay. template was stopped when you deployed the ubunut service though? [00:05] waigani: so this is what I hve in my environment.yaml under local: http://pastebin.ubuntu.com/11956665/ [00:06] veebers: could you dump the logs somewhere I can take a look at them? [00:07] waigani: can do, let me make sure I'm not posting secret/private [arts [00:08] veebers: this looks like you: https://bugs.launchpad.net/juju-core/+bug/1364939 [00:08] Bug #1364939: container failed to start with lxc-clone-aufs=true

[00:09] fix released in 1.21 [00:10] waigani: hmm interesting, so either I need to go to 1.21 or perhaps just remove that from my config? [00:11] veebers: yeah, I'd say so. Go to 1.21 if you can. [00:12] waigani: which would mean a distro upgrade right? Not avaiable on utopic? [00:15] veebers: you can add a ppa: ppa:juju/stable [00:15] waigani: ah, no way :-) sweet, I'll give that a hoon and see how it goes [00:15] cheers waigani, if this works out I'll owe you a beer or 2 [00:15] veebers: code craft is coming up.... ;) [00:16] waigani: ^_^ [00:18] 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] waigani: heh, I only want something that works, not the bleeding edge ;-) [00:20] veebers: fair enough - isn't that what we all want? [00:21] ^_^ [02:11] jose: pong [02:12] 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] and now I can't find the MP [02:12] do you by chance remember what it was? [02:17] 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] 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] oh, ok, thanks [02:26] waigani: ah you lucked out, I had another problem but I solved it myself ;-) [02:27] had to kill the old juju agents as it was blocking my bootstrap attempts [02:34] veebers: waigani: That looks a lot like a race condition I reported last week. [02:35] or the one I'm tracking down right now [02:35] are you seeing it with a current version of juju? [02:36] 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] veebers: ack, just reading through my scrollback. [02:37] good to hear it's fixed for you! [02:38] Well, I'm getting further now at any rate :-) === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob === zz_CyberJacob is now known as CyberJacob [09:48] 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] marcoceppi: debian/copyright needs adding, and debian/changelog updating to match the archive rather than the PPA. [09:49] marcoceppi: I'd like to look into why the .postinst is required. [09:49] marcoceppi: nothing else leapt out to me. Nothing major that I could see on a quick glance. [09:50] marcoceppi: do you want to start a packaging branch somewhere to start fixing that up? [12:07] rbasak: yeah, what do I need to do to start a packaging branch? [12:07] I've got the changelog without ppa stuff already [12:07] marcoceppi: easiest to have a branch that adds the debian directory with all its contents [12:08] So then the debian directory can evolve independently of "upstream" as packaging fixes are made [14:24] 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] Bug #1478061: subordinate config data is being dropped for nova.conf

[14:25] https://code.launchpad.net/~gnuoy/charm-helpers/subconfs-multi-sections/+merge/266237 === CyberJacob is now known as zz_CyberJacob [15:39] 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] gnuoy, +1 on that fix [15:52] jamespage, thanks [16:11] beisner, I'm hoping lp:~gnuoy/charms/trusty/nova-compute/subctxt-fix will fix it [16:15] 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] yep [16:15] gnuoy, perhaps the n-c amulet test should incorporate subordinates in its tests anyway. [16:15] 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] s/from that/for specifying alternative branches in amulet tests/ [16:38] gnuoy, ah yes very good. i've also put some thought into how to approach that, but no WIP yet. [17:26] 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] gnuoy, wolsen, jamespage - 3 oopsie-MPs to expedite if you will, necessary for final checks before the 1507 push: [18:41] https://code.launchpad.net/~1chb1n/charms/trusty/neutron-gateway/next1507-amulet-cleanup/+merge/266289 [18:41] https://code.launchpad.net/~1chb1n/charms/trusty/neutron-api/next1507-amulet-cleanup/+merge/266279 [18:41] https://code.launchpad.net/~1chb1n/charms/trusty/hacluster/next1507-amulet-cleanup/+merge/266298 [18:46] beisner, looking [18:47] wolsen, much appreciated [18:48] 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] wolsen, but the others don't functionally impact the tests like those 3 could ^ [18:48] beisner, completely agree ... these look to remove the utopic tests [18:49] 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] wolsen, should just be --utopic [18:50] beisner, that's what i understood as well [18:50] 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] beisner, I have a feeling that stable=True/False flag might fail to get updated somewhere between /next and /trunk [18:53] ;) [18:53] wolsen, fwiw (shhh. i've had utopic-juno blacklisted / not-run since it EOL'd last week.) [18:53] heh [18:53] wolsen, yep it's on our post-release checklist [18:54] wolsen, i have a batch for that. [18:54] sweet [18:54] 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] beisner, that's cool - just let me know [18:55] wolsen, thx man [18:57] 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] beisner, yep yep [18:58] beisner, oy wish the quantum-gateway to neutron-gateway had been caught in the neturon-api a bit earlier [18:58] 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] wolsen, yeah. [18:59] wolsen, oy. i really wanna hammer the whole set of amulet tests on all next charms again once that lands. [18:59] 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] 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] wolsen, yep - added to list ;-) [19:00] beisner, thx [19:07] what is the difference between the launchpad and github versions of juju? [19:07] beisner, done [19:08] beisner, thanks for making them fairly trivial :) [19:09] wolsen, thanks a ton! [19:15] or is the github version supposed to be a mirror of the launchpad code? [19:17] nevermind ;) [19:17] 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] wolsen, bored yet? here's a pile o' trivials: http://paste.ubuntu.com/11961606/ [20:17] beisner, I'll queue em up for this afternoon === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob === zz_CyberJacob is now known as CyberJacob [22:03] 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 === CyberJacob is now known as zz_CyberJacob