[04:41] Bug #1499571 opened: Restore failed: error fetching address

[04:44] Bug #1499571 changed: Restore failed: error fetching address

[04:47] Bug #1499571 opened: Restore failed: error fetching address

[04:50] Bug #1499571 changed: Restore failed: error fetching address

=== akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [09:03] TheMue: dooferlad: grabbing coffee, with you in 5 minutes [09:03] sorry [09:37] TheMue, ping? [09:37] mattyw: pong! === akhavr1 is now known as akhavr [09:38] TheMue, just reviewing http://reviews.vapour.ws/r/2820. On the whole it looks great, couple of questions though [09:38] TheMue, 1) the juju/helptopics stuff. that documentation is available through the command line right? [09:39] mattyw: exactly, and I'm currently porting and extending it to jujucharms.com [09:39] 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] TheMue, you mean so the docs will appear on jujucharms.com? [09:40] 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] mattyw: yes, they will [09:40] 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] mattyw: the spreading is done via constraints, but it's a good hint if you want them more detailed [09:41] mattyw: you're looking on it as a user :) [09:41] TheMue, I'm published my comments so far [09:42] 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] 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] mattyw: ok, will add it [09:43] 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] mattyw: great, so I've already got a reviewer for it, thx === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [10:11] dooferlad: ping [10:11] voidspace: pong [10:13] dooferlad: bridgeConfigTemplate in provider/maas/environ.go [10:13] dooferlad: it starts by attempting to detect if the bridge has already been setup [10:13] dooferlad: the first line is: [10:13] grep -q "iface {{.Bridge}} inet dhcp" && exit 0 [10:14] dooferlad: it seems to me that's buggy, as it's missing the filename argument to grep (?) [10:14] I believe it should be [10:14] grep -q "iface {{.Bridge}} inet dhcp" {{.Config}} && exit 0 [10:14] would you concur? [10:15] voidspace: Yes [10:15] dooferlad: thanks [10:15] voidspace: np [10:16] voidspace: though grep will wait for stdin if you don't pass it a file [10:17] voidspace: don't know if the script assumes it will be piped the current file? [10:17] dooferlad: right, but I don't think that's how we're using it (and it's executed on a non tty) [10:17] voidspace: seems buggy anyway [10:17] dooferlad: we pass in .Config to the template, so I don't see why we would also pass in the file [10:17] a later invocation of grep uses {{.Config}} [10:17] dooferlad: I'll try and double check we're not passing the file [10:19] 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] I guess that invocation of grep always terminated with a non-zero exit code so it was effectively always ignored [10:19] voidspace: how can that possibly work then? Grep will just sit waiting for input... [10:20] on a non-tty won't it just immediately exit with an error [10:20] as it can't get any input [10:20] voidspace: ah, yes === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === jamespag` is now known as jamespage === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [14:56] cmars: FYI, I've merged master into the lxd-provider branch and added the missing dependencies [14:57] ericsnow, awesome stuff [14:57] cmars: yeah, keep an eye on that branch [15:01] 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] dooferlad: I don't know. [15:05] natefinch: thanks. Will reach out on list. [15:05] dooferlad: I have some guesses, because we do run things in different processes occasionally, but I don't know the details. [15:08] 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! === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [15:37] Bug #1503740 opened: Storage should be behind a feature flag in 1.24 [15:40] Bug #1503740 changed: Storage should be behind a feature flag in 1.24 === akhavr1 is now known as akhavr [15:43] Bug #1503740 opened: Storage should be behind a feature flag in 1.24 === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [15:56] does anyone actually understand bug 1501563? [15:56] Bug #1501563: 1.26-alpha1 client gets connection shutdown deploy 1.22 server

[16:07] Bug #1474588 changed: Many hook failures after upgrade

[16:10] Bug #1474588 opened: Many hook failures after upgrade

=== akhavr1 is now known as akhavr [16:13] Bug #1474588 changed: Many hook failures after upgrade

[16:14] mgz: nope, not really clear what is going on there [16:15] mgz: it would seem that apiserver abruptly cuts off while colocating a charm === akhavr1 is now known as akhavr [16:33] perrito666: would --debug logging help? [16:33] tasdomas: looks like dafe43b5683c9b22af86ee744a8ea7f088b087b6 caused bug 1501563 - any idea why? [16:33] Bug #1501563: 1.26-alpha1 client gets connection shutdown deploy 1.22 server

=== akhavr1 is now known as akhavr [16:42] 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] natefinch: yep [16:43] mgz: might, but not sure [16:44] mgz: depends if we actually put debug messages around the broken part === akhavr1 is now known as akhavr [16:45] perrito666: indeed, which is why I was asking if you had an inkling :) [16:45] we could also just try removing tasdomas' change [16:46] seems to have another branch on top of it though === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [17:35] rogpeppe: is there anything special that needs to be done relative to adding a new top-level section to metadata.yaml? [17:35] rogpeppe: as far as I can see it's pretty straight-forward [17:37] ericsnow: see katherine's response in email - it's about the code not the yaml [17:38] natefinch: yeah, that's what I'm asking about === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [19:22] ericsnow: technically you don't need to do anything in the charm package at all [19:23] rogpeppe: does it ignore unrecognized entries? [19:23] ericsnow: yeah, you can have any files you like in a charm [19:23] ericsnow: it's just a zip file [19:23] rogpeppe: I mean unrecognized entries in metadata.yaml itself [19:24] ericsnow: i thought you were adding a new file [19:24] rogpeppe: no longer [19:24] ericsnow: what's this for? [19:24] same thing, new name [19:24] rogpeppe: same feature (now called "payloads" [19:24] ) [19:25] rogpeppe: we have to move it back into metadata.yaml [19:25] ericsnow: i'm pretty sure that metadata.yaml isn't the right place - that's the public interface of the charm [19:25] ericsnow: and this isn't actually something that's part of that, right? [19:25] rogpeppe: it's not my call [19:25] rogpeppe: agreed [19:25] ericsnow: so wtf? [19:26] rogpeppe: this is the direction we have been given from the highest levels of the echelon [19:27] natefinch: well if he wants the model broken, i guess we'll have to break it [19:28] rogpeppe: yep [19:28] rogpeppe: we argued it and other things for a month or so, and at the sprint the law was laid down. [19:31] ericsnow: so anyway, charm.ReadMeta does ignore extra members [19:31] ericsnow: so you can easily add more if you want to [19:32] rogpeppe: in that case we could avoid adding any code to the charm repo [19:32] rogpeppe: we'd just parse out the extra bits we care about [19:32] ericsnow: i'm not sure [19:32] rogpeppe: I'm fine either way [19:33] ericsnow: i think that the metadata.yaml parsing code in charm should parse all the metadata [19:33] ericsnow: otherwise you'll need to do nasty things like re-parse and second-guess the format [19:36] rogpeppe: k [19:37] 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] ericsnow: it depends really === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [20:22] cherylj: https://bugs.launchpad.net/juju-core/+bug/1468349 [20:22] Bug #1468349: discoverySuite.TestDiscoverServiceLocalHost: invalid series for wily and vivid

[20:22] thanks, sinzui === akhavr1 is now known as akhavr [20:47] rogpeppe: what natefinch says is true [20:47] katco: i believe it [20:52] katco: that was a powerful statement [20:52] perrito666: lol didn't catch that === akhavr1 is now known as akhavr [20:54] katco: ? [20:55] perrito666: i didn't mean to say that everything nate says is true ;) [20:56] perrito666: because now i have introduced a tautilogical fallacy. as soon as he says "this statement is false", i am wrong === akhavr1 is now known as akhavr [20:57] oh great, now you broke the universe [20:59] rogpeppe: poké [20:59] rogpeppe: any idea where the bits and pieces you ran to clean up txn db things for 1.23 issues are? [20:59] mgz: oh twats, i saw that email out of hours and forgot to reply this morning [21:00] mgz: one mo === akhavr1 is now known as akhavr [21:06] rogpeppe: merci [21:07] mgz: so the main thing is https://github.com/rogpeppe/mgo/pull/2/files [21:07] mgz: which is a patch to mgo (not accepted) [21:08] mgz: and then there's mgopurge.go: http://paste.ubuntu.com/12708968/ [21:08] mgz: which actually does the job === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === bradm_ is now known as bradm === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [23:53] wallyworld: bug 1452422 - but see also bug 1271744 [23:54] Bug #1452422: Cannot boostrap from custom image-metadata-url or by specifying metadata-source

[23:54] Bug #1271744: bootstrap on maas with --metadata-source fails

=== akhavr1 is now known as akhavr