[04:38] <mup> Bug #1499571 changed: Restore failed: error fetching address <backup-restore> <blocker> <ci> <regression> <reliability> <retry> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1499571>
[04:41] <mup> Bug #1499571 opened: Restore failed: error fetching address <backup-restore> <blocker> <ci> <regression> <reliability> <retry> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1499571>
[04:44] <mup> Bug #1499571 changed: Restore failed: error fetching address <backup-restore> <blocker> <ci> <regression> <reliability> <retry> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1499571>
[04:47] <mup> Bug #1499571 opened: Restore failed: error fetching address <backup-restore> <blocker> <ci> <regression> <reliability> <retry> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1499571>
[04:50] <mup> Bug #1499571 changed: Restore failed: error fetching address <backup-restore> <blocker> <ci> <regression> <reliability> <retry> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1499571>
[09:03] <voidspace> TheMue: dooferlad: grabbing coffee, with you in 5 minutes
[09:03] <voidspace> sorry
[09:37] <mattyw> TheMue, ping?
[09:37] <TheMue> mattyw: pong!
[09:38] <mattyw> TheMue, just reviewing http://reviews.vapour.ws/r/2820. On the whole it looks great, couple of questions though
[09:38] <mattyw> TheMue, 1) the juju/helptopics stuff. that documentation is available through the command line right?
[09:39] <TheMue> mattyw: exactly, and I'm currently porting and extending it to jujucharms.com
[09:39] <mattyw> TheMue, 2) There didn't seem to be any documentation about how to get units to spread across availability zones. is that documentation there somewhere (did I miss it or is it missing)
[09:40] <mattyw> TheMue, you mean so the docs will appear on jujucharms.com?
[09:40] <TheMue> mattyw: btw, 1.25 already as this branch in. has been a start on master, a backport to 1.25 due to needs, and then adopting the changes in master again
[09:40] <TheMue> mattyw: yes, they will
[09:40] <mattyw> TheMue, ok - my comments are only minor spelling things, and one place I'd like a bit more of an example, I'll let you work out where best to merge those in
[09:41] <TheMue> mattyw: the spreading is done via constraints, but it's a good hint if you want them more detailed
[09:41] <TheMue> mattyw: you're looking on it as a user :)
[09:41] <mattyw> TheMue, I'm published my comments so far
[09:42] <mattyw> TheMue, regarding the spreading across zones. I'd like to see examples of command line commands - and what you end up with. similar to my comment regarding the dmz/cms subnets example
[09:42] <mattyw> I like seeing examples that say "if you run these commands at the command line this is the setup you end up with"
[09:43] <TheMue> mattyw: ok, will add it
[09:43] <mattyw> TheMue, you're great, thanks very much. let me know when there's a pr for jujucharms.com. Very excited about seeing that
[09:44] <TheMue> mattyw: great, so I've already got a reviewer for it, thx
[10:11] <voidspace> dooferlad: ping
[10:11] <dooferlad> voidspace: pong
[10:13] <voidspace> dooferlad: bridgeConfigTemplate in provider/maas/environ.go
[10:13] <voidspace> dooferlad: it starts by attempting to detect if the bridge has already been setup
[10:13] <voidspace> dooferlad: the first line is:
[10:13] <voidspace> grep -q "iface {{.Bridge}} inet dhcp" && exit 0
[10:14] <voidspace> dooferlad: it seems to me that's buggy, as it's missing the filename argument to grep (?)
[10:14] <voidspace> I believe it should be
[10:14] <voidspace> grep -q "iface {{.Bridge}} inet dhcp" {{.Config}} && exit 0
[10:14] <voidspace> would you concur?
[10:15] <dooferlad> voidspace: Yes
[10:15] <voidspace> dooferlad: thanks
[10:15] <dooferlad> voidspace: np
[10:16] <dooferlad> voidspace: though grep will wait for stdin if you don't pass it a file
[10:17] <dooferlad> voidspace: don't know if the script assumes it will be piped the current file?
[10:17] <voidspace> dooferlad: right, but I don't think that's how we're using it (and it's executed on a non tty)
[10:17] <dooferlad> voidspace: seems buggy anyway
[10:17] <voidspace> dooferlad: we pass in .Config to the template, so I don't see why we would also pass in the file
[10:17] <voidspace> a later invocation of grep uses {{.Config}}
[10:17] <voidspace> dooferlad: I'll try and double check we're not passing the file
[10:19] <voidspace> dooferlad: the script is executed via cloudcfg.AddRunCmd which has no mechanism for passing a file (unless it's done via the command itself - which it isn't)
[10:19] <voidspace> I guess that invocation of grep always terminated with a non-zero exit code so it was effectively always ignored
[10:19] <dooferlad> voidspace: how can that possibly work then? Grep will just sit waiting for input...
[10:20] <voidspace> on a non-tty won't it just immediately exit with an error
[10:20] <voidspace> as it can't get any input
[10:20] <dooferlad> voidspace: ah, yes
[14:56] <ericsnow> cmars: FYI, I've merged master into the lxd-provider branch and added the missing dependencies
[14:57] <cmars> ericsnow, awesome stuff
[14:57] <ericsnow> cmars: yeah, keep an eye on that branch
[15:01] <dooferlad> natefinch: Hi, do you know much about why the uniter hook execution lock is file based and isn't reset on startup? I thought we only had one jujud running, so the choice seems odd.
[15:05] <natefinch> dooferlad: I don't know.
[15:05] <dooferlad> natefinch: thanks. Will reach out on list.
[15:05] <natefinch> dooferlad: I have some guesses, because we do run things in different processes occasionally, but I don't know the details.
[15:08] <dooferlad> natefinch: Ah, didn't know we had >1 process running sometimes. I have been tracking down a problem where the lock doesn't get released because the host is rebooted. Clearly nothing has it at that point!
[15:37] <mup> Bug #1503740 opened: Storage should be behind a feature flag in 1.24 <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1503740>
[15:40] <mup> Bug #1503740 changed: Storage should be behind a feature flag in 1.24 <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1503740>
[15:43] <mup> Bug #1503740 opened: Storage should be behind a feature flag in 1.24 <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1503740>
[15:56] <mgz> does anyone actually understand bug 1501563?
[15:56] <mup> Bug #1501563: 1.26-alpha1 client gets connection shutdown deploy 1.22 server <blocker> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1501563>
[16:07] <mup> Bug #1474588 changed: Many hook failures after upgrade <canonical-bootstack> <regression> <juju-core:Incomplete by menno.smits> <juju-core 1.24:Incomplete> <https://launchpad.net/bugs/1474588>
[16:10] <mup> Bug #1474588 opened: Many hook failures after upgrade <canonical-bootstack> <regression> <juju-core:Incomplete by menno.smits> <juju-core 1.24:Incomplete> <https://launchpad.net/bugs/1474588>
[16:13] <mup> Bug #1474588 changed: Many hook failures after upgrade <canonical-bootstack> <regression> <juju-core:Incomplete by menno.smits> <juju-core 1.24:Incomplete> <https://launchpad.net/bugs/1474588>
[16:14] <perrito666> mgz: nope, not really clear what is going on there
[16:15] <perrito666> mgz: it would seem that apiserver abruptly cuts off while colocating a charm
[16:33] <mgz> perrito666: would --debug logging help?
[16:33] <mgz> tasdomas: looks like dafe43b5683c9b22af86ee744a8ea7f088b087b6 caused bug 1501563 - any idea why?
[16:33] <mup> Bug #1501563: 1.26-alpha1 client gets connection shutdown deploy 1.22 server <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1501563>
[16:42] <natefinch> ericsnow: I'm just going to write a new command from scratch, unless you object?   Seems like all the work we did for the base command stuff does not apply to the new command structure
[16:43] <ericsnow> natefinch: yep
[16:43] <perrito666> mgz: might, but not sure
[16:44] <perrito666> mgz: depends if we actually put debug messages around the broken part
[16:45] <mgz> perrito666: indeed, which is why I was asking if you had an inkling :)
[16:45] <mgz> we could also just try removing tasdomas' change
[16:46] <mgz> seems to have another branch on top of it though
[17:35] <ericsnow> rogpeppe: is there anything special that needs to be done relative to adding a new top-level section to metadata.yaml?
[17:35] <ericsnow> rogpeppe: as far as I can see it's pretty straight-forward
[17:37] <natefinch> ericsnow: see katherine's response in email - it's about the code not the yaml
[17:38] <ericsnow> natefinch: yeah, that's what I'm asking about
[19:22] <rogpeppe> ericsnow: technically you don't need to do anything in the charm package at all
[19:23] <ericsnow> rogpeppe: does it ignore unrecognized entries?
[19:23] <rogpeppe> ericsnow: yeah, you can have any files you like in a charm
[19:23] <rogpeppe> ericsnow: it's just a zip file
[19:23] <ericsnow> rogpeppe: I mean unrecognized entries in metadata.yaml itself
[19:24] <rogpeppe> ericsnow: i thought you were adding a new file
[19:24] <ericsnow> rogpeppe: no longer
[19:24] <rogpeppe> ericsnow: what's this for?
[19:24] <natefinch> same thing, new name
[19:24] <ericsnow> rogpeppe: same feature (now called "payloads"
[19:24] <ericsnow> )
[19:25] <ericsnow> rogpeppe: we have to move it back into metadata.yaml
[19:25] <rogpeppe> ericsnow: i'm pretty sure that metadata.yaml isn't the right place - that's the public interface of the charm
[19:25] <rogpeppe> ericsnow: and this isn't actually something that's part of that, right?
[19:25] <ericsnow> rogpeppe: it's not my call
[19:25] <ericsnow> rogpeppe: agreed
[19:25] <rogpeppe> ericsnow: so wtf?
[19:26] <natefinch> rogpeppe: this is the direction we have been given from the highest levels of the echelon
[19:27] <rogpeppe> natefinch: well if he wants the model broken, i guess we'll have to break it
[19:28] <natefinch> rogpeppe: yep
[19:28] <natefinch> rogpeppe: we argued it and other things for a month or so, and at the sprint the law was laid down.
[19:31] <rogpeppe> ericsnow: so anyway, charm.ReadMeta does ignore extra members
[19:31] <rogpeppe> ericsnow: so you can easily add more if you want to
[19:32] <ericsnow> rogpeppe: in that case we could avoid adding any code to the charm repo
[19:32] <ericsnow> rogpeppe: we'd just parse out the extra bits we care about
[19:32] <rogpeppe> ericsnow: i'm not sure
[19:32] <ericsnow> rogpeppe: I'm fine either way
[19:33] <rogpeppe> ericsnow: i think that the metadata.yaml parsing code in charm should parse all the metadata
[19:33] <rogpeppe> ericsnow: otherwise you'll need to do nasty things like re-parse and second-guess the format
[19:36] <ericsnow> rogpeppe: k
[19:37] <rogpeppe> ericsnow: that's not to say it has to be specified in total detail with all allowed keys etc. it's sometimes possible to allow a more general format and add more specific checks at higher levels
[19:37] <rogpeppe> ericsnow: it depends really
[20:22] <sinzui> cherylj: https://bugs.launchpad.net/juju-core/+bug/1468349
[20:22] <mup> Bug #1468349: discoverySuite.TestDiscoverServiceLocalHost: invalid series for wily and vivid <centos> <test-failure> <unit-tests> <vivid> <wily> <juju-core:Fix Released by dooferlad> <juju-core 1.24:Won't Fix> <https://launchpad.net/bugs/1468349>
[20:22] <cherylj> thanks, sinzui
[20:47] <katco> rogpeppe: what natefinch says is true
[20:47] <rogpeppe> katco: i believe it
[20:52] <perrito666> katco: that was a powerful statement
[20:52] <katco> perrito666: lol didn't catch that
[20:54] <perrito666> katco: ?
[20:55] <katco> perrito666: i didn't mean to say that everything nate says is true ;)
[20:56] <katco> perrito666: because now i have introduced a tautilogical fallacy. as soon as he says "this statement is false", i am wrong
[20:57] <perrito666> oh great, now you broke the universe
[20:59] <mgz> rogpeppe: poké
[20:59] <mgz> rogpeppe: any idea where the bits and pieces you ran to clean up txn db things for 1.23 issues are?
[20:59] <rogpeppe> mgz: oh twats, i saw that email out of hours and forgot to reply this morning
[21:00] <rogpeppe> mgz: one mo
[21:06] <mgz> rogpeppe: merci
[21:07] <rogpeppe> mgz: so the main thing is https://github.com/rogpeppe/mgo/pull/2/files
[21:07] <rogpeppe> mgz: which is a patch to mgo (not accepted)
[21:08] <rogpeppe> mgz: and then there's mgopurge.go: http://paste.ubuntu.com/12708968/
[21:08] <rogpeppe> mgz: which actually does the job
[23:53] <mgz> wallyworld: bug 1452422 - but see also bug 1271744
[23:54] <mup> Bug #1452422: Cannot boostrap from custom image-metadata-url or by specifying metadata-source <sts> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Fix Released by wallyworld> <https://launchpad.net/bugs/1452422>
[23:54] <mup> Bug #1271744: bootstrap on maas with --metadata-source fails <bootstrap> <maas> <maas-provider> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1271744>