[00:07] thanks for the review thumper === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [03:31] wallyworld, thumper: joyent fix: http://reviews.vapour.ws/r/633/ [03:32] wallyworld, thumper: I spent a long time trying to make a unit test for this work [03:32] wallyworld, thumper: but it looks like there's something missing from the fake Joyent API implementation [03:35] menn0: lgtm [03:35] menn0: u r a Joyent champion now :D [03:38] wallyworld: cheers. Just fixing commit message text as it doesn't quite make sense and will then merge. [03:38] anastasiamac_: oh no you don't... :) [03:39] hey yeah, that gets me off the hook :-D [03:39] menn0: kkkk... if u get CI unblocked - then u r a champion?... [03:40] wallyworld: there mayb a room for joyent fan club... [03:40] anastasiamac_: maybe, but I don't think this is the entire fix because Joyent is consistently failing for master [03:40] anastasiamac_: I think there might be another problem to fix yet [03:40] anastasiamac_: looking at that now [03:41] menn0: there must b - it would not b xmas without more problems to fix :p [03:41] menn0: thnx! [03:54] menn0, ping? [03:57] mattyw: pong! [04:01] sorry, was drinking coffee and arguing with kids on holiday [04:02] anastasiamac_: I feel like you type like teenagers text now :-) [04:02] thumper: why? [04:04] 'u' 'r' [04:05] menn0: I see that wallyworld has reviewed already and I don't need to do anything [04:06] thumper: correct :) [04:10] \o/ [04:21] thumper: i think and type young [04:21] bwahaha [04:24] * anastasiamac_ considers whether it's worthwhile to be offended [04:28] no, don't be offende [04:28] d [04:31] wallyworld, thumper: the merge job seems to have gotten stuck. [04:31] wallyworld, thumper: it's been like this for a long time: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1595/console [04:32] menn0: I'd give it 20 minutes [04:32] i've seen it take a while [04:32] menn0: how long? [04:33] thumper: at least half an hour at this point in the tests [04:33] hmm... [04:33] well... [04:33] i'm running the apiserver tests for this branch locally now [04:33] the test timeout is 20 minutes [04:33] and there are multiple slow packages there [04:33] and it buffers the output [04:34] so it is hard to say [04:34] thumper: ok, so i'll wait [04:34] but normally it is done in under 20 minutes for everything... [04:34] so perhaps it is wedged [04:34] wallyworld: do you know how to kick it right? [04:34] yes [04:34] i can restart it [04:35] wallyworld, thumper: the apiserver tests have gotten past that point on my machine already [04:36] menn0: thumper: jon restarted [04:36] job [04:36] wallyworld: cheers [04:37] do i need something special for juju/names? [04:37] I am getting http://pastebin.ubuntu.com/9524130/ [04:38] anastasiamac_: shouldn't do, let me check [04:38] anastasiamac_: pretty sure that access control is for everything under github.com/juju [04:39] anastasiamac_: nope, you are there [04:39] anastasiamac_: what is your remote set to? [04:40] thumper: i ran git remote add upstream https://github.com/juju/names.git [04:40] remote set-url origin git@github.com:anastasiamac/names.git [04:41] anastasiamac_: have you forked it? [04:41] on github? [04:41] thumper: :D yes [04:41] only asking because I have forgotten before [04:41] thumper: i forked it first [04:41] then ran cmds above [04:42] anastasiamac_: FYI, I would do the following: [04:42] i can do pretty much everything - run status, etc... but cannot pull ;( [04:42] git remote --set-url upstream git@github.com/juju/names.git [04:42] git remote --set-url --push upstream no-pushing [04:43] the git wire protocol is much faster than https [04:43] anastasiamac_: dumb question, have you added your public SSH key to GitHub? [04:44] (are you using SSH for juju/juju?) [04:44] axw: i must have to commit to juju/juju no? [04:44] there are other transports [04:44] axw: dunno... how can i find out what m using for juju/juju [04:44] axw: ? [04:44] anastasiamac_: "git remote -vv" in the local repo [04:46] axw: fetch and pull for origin and upstream are prefixed with https [04:47] anastasiamac_: right, so you're not using SSH. if you want to use it, then you should add your public key in your user settings on GitHub [04:47] anastasiamac_: https://github.com/settings/ssh [04:48] axw: i dont want ssh :) [04:48] axw: but m seeing the diff btw how my juju/juju and juju/names are setup.. [04:48] axw: let me align them with party line [04:50] anastasiamac_: git remote set-url origin https://github.com/anastasiamac/names.git [04:50] anastasiamac_: why don't you want ssh? [04:50] ssh is awesome [04:50] if you really don't want SSH... I would use it though, you don't need to keep putting your password in [04:52] axw: thnx. i've sorted and will consider ssh :D u r awesome! === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [05:14] and we have a new CI blocker.... [05:14] https://bugs.launchpad.net/juju-core/+bug/1402495 [05:14] Bug #1402495: Joyent deploys fail in CI

[05:15] with the Joyent routing issue fixed, this CI with Joyent issue remains === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [06:50] folks - is juju/utils a review board project now? [07:09] mattyw: it looks like it :-) [07:12] anastasiamac_, :) I was sure I saw an old email that said it was, I saw it and went for it :) === urulama_ is now known as urulama === negronjl is now known as negronjl_afk [09:02] morning TheMue [09:02] TheMue, 1:1? [09:05] fwereade, hey [09:07] fwereade, if you're around today, and hopefully feeling better, can I trouble you for a review on http://reviews.vapour.ws/r/611/ please? [09:09] morning [09:10] dimitern: oh, eh, yes, coming [09:24] morning [09:28] dimitern, not better, but looking anyway, because it looks completely awesome from the description and I feel bad for not having done it on fri [09:28] fwereade, cheers :) [09:50] morning perrito666, voidspace [09:55] dimitern, that's *awesome*, LGTM with trivials [09:55] dimitern, check with TheMue about YamlEquals though [09:55] dimitern: morning [09:55] perrito666: o/ [09:55] fwereade, thank you very much! [09:55] fwereade: o/ [09:56] fwereade: sorry you're still unwell [09:56] my wife brought a cold into the house - she's had it for more than two weeks [09:56] and it's been rumbling on and off with me for a week [09:56] not bad, just annoying [11:54] fwereade: hiya [11:56] anyone know when it's ok to call "unit-get public-address" from a charm hook? [11:57] is it supposed to be ok to call it in the install hook for example? [11:57] dimitern: ^ [11:58] rogpeppe1, it's set when the uniter starts (if it's available) so I'd say right away [11:59] dimitern: ok, thanks [12:00] rogpeppe1, it might not be available if the machine doesn't have an address yet (i.e. still pending/provisioning) [12:05] hey axw, wallyworld, maybe we should be chatting here instead :) [12:05] maybe [12:05] jam1, o/ [12:06] hi dimitern, how's your day been going? [12:07] dimitern: thanks [12:07] dimitern: one other thing: if you call config-get in an install hook, should you get something sensible? [12:08] jam1, not bad, multitasking already :) with goamz migration, ci blockers and addressability stuff.. [12:09] rogpeppe1, you know what - I was just looking at the code and I can't say I'm 100% sure the install hook will have public-address set [12:09] rogpeppe1: given you can do "juju deploy —config=" why wouldn't you get config in install ? [12:09] rogpeppe1, better ask fwereade for sure [12:10] jam1: i *think* i'm seeing a null result from config-get in an install hook; i need to check a bit more [12:11] rogpeppe1, config-get should always be fine; I *think* unit-get public address should always work but it's possible that state and/or networking changes have made it "" instead of [12:11] fwereade: ok, thanks. it's probably my code. [12:12] rogpeppe1, sorry I'm not very around today, I'm mostly in bed, will be on a bit later for meetings [12:12] fwereade: aw, gbs [12:12] jam1: heya. chatting about what? is there a meeting? [12:13] axw: jam1 was look at storage spec, but the 15.04 "official" one in the master spec list pointed to the old spec, not the newest, latest one [12:14] ok [12:15] fwereade, rogpeppe1, unit-get private-address|public-address always triggers unit.Private|PublicAddress() getting called; however looking at the filter/modes/etc. it seems until we know there's an address (i.e. the addresses watcher returned changes) config-change won't be triggered [12:16] dimitern, not *quite* true, we always get a config-changed after install, so, ha, yes, it's possible that nothing's set the machine's address by the time it's running a unit [12:16] dimitern: the behaviour i *think* i'm seeing (i'm just about the test it) is that config-get is returning a null value even when there's a default value set [12:16] dimitern: this is in the install hook [12:16] s/the test/to test/ [12:17] rogpeppe1, that seems odd, for sure, what do you get with --all? [12:17] fwereade: not sure yet - i haven't got a hook context to play with [12:17] rogpeppe1, juju-run? [12:18] fwereade: ok, trying that [12:19] fwereade: should this work? juju run --unit identity/0 -- config-get --all [12:19] rogpeppe1, why config-get ? [12:20] rogpeppe1, can't remember if you use -- or quote the command [12:20] rogpeppe1, it should be unit-get [12:20] dimitern: i'm interested in config values here [12:21] rogpeppe1, private|public-address is not a config setting, it's a separate thing [12:21] dimitern: yeah, i know. i was asking about public address initially, but i think the problem may lie elsewhere [12:22] rogpeppe1, ah, ok [15:08] dimitern, how goes bug 1397376? [15:08] Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints

[15:09] sinzui, fixing last suggestions from fwereade and setting to land [15:09] rock [15:11] sinzui, I'm already working on the backport for 1.21 as well [15:11] rock [15:14] with markdown everywhere how are you supposed to curse politely? s**t becomes s[bold]t[/bold] :) I guess s\*\*t is the way to go [15:33] sinzui, should I JFDI it? [15:34] Does not match ['fixes-1401130', 'fixes-1400358']; Build rejected, reporting on proposal - both of these are fix committed btw [15:34] dimitern, __JFDI__ for master [15:35] sinzui, ok === kadams54 is now known as kadams54-away [15:41] hi, could someone please point me to where should I look to get the info shown in "state-server-member-status" from the delta stream? [15:43] marcoceppi: I think I just opened the doc for comments, could you try? [15:44] perrito666: :thumbsup: will circle back in a bit, got other things I need to clear out first [15:44] marcoceppi: np jut shout if it still not open when you try again, google docs hates me sometimes [15:44] perrito666: it's open, thanks! [15:47] rogpeppe1, did you just merge http://reviews.vapour.ws/r/636/ into utils? [15:48] rogpeppe1, sinzui, this causes the CI bot to fail with: Extant directories unknown: [15:48] golang.org/x/crypto [15:51] dimitern, looks like something got imported that wasn't documented [15:52] sinzui, that's right - but it's coming from juju/utils [15:53] dimitern, I believe the simple fix is to add it to dependencies.tsv. [15:54] dimitern, I don't think this is like the cases were conflicting or ambiguous licensing prevent the package from being included. We just need to document it [15:55] sinzui, to unblock the bot, yeah [15:55] right [15:55] sinzui, but we need to make sure this doesn't happen again, agreed? [15:56] sinzui, that fits in just perfect with what I wanted to discuss with you guys - bringing juju-core dependencies under the ci bot (or at least the more actively developed ones) [15:57] sinzui, which will force the devs to actually care about the CI/release process more - like adding a dependencies.tsv for juju/utils, etc. and making sure it works before just merging changes [15:57] dimitern, the check_dependencies phase of building the release tarball ensures no deps that aren't in dependencies.tsv are included. The inclusion assumes we checked the license of the package and pinned it to a version we know is good [15:57] sinzui, even simpler fix will be to actually revert rogpeppe1's change to utils and ask him to do it properly :) [15:58] dimitern, yep [15:58] sinzui, that's totally fine and good we have this check [15:58] dimitern: what was the problem with my change to utils? [15:58] sinzui, it actually helped to catch this === kadams54-away is now known as kadams54 [15:59] rogpeppe1, you added a dependency which wasn't mentioned anywhere and caused the build to potentially fail (it didn't due to a precaution on the bot) [15:59] dimitern: why should that cause the build to fail? [15:59] dimitern: aren't juju deps pinned? [15:59] rogpeppe1, because it's not in dependecies.tsv of juju-core [15:59] dimitern: but juju-core won't be getting the latest version of utils [15:59] rogpeppe1, and the bot verifies all imports are properly listed as deps [15:59] dimitern: because dependencies.tsv will mention an earlier version [16:00] rogpeppe1, that sounds right... hmm why did it happen then? [16:00] dimitern: i don't see why making a change to utils tip could have broken juju-core, unless someone updated juju-core deps improperly [16:01] rogpeppe1, can you please work with sinzui to see how this could've happened and how to fix the bot? [16:01] dimitern, rogpeppe1 is Juju importing a non-master branch in this case? [16:01] I have a pending bugfix which can't land because of that [16:01] dimitern: i'm in a standup right now [16:01] sinzui: not AFAIK [16:01] rogpeppe1, np, later then? [16:02] dimitern: possibly, although i'm quite busy [16:02] thank you rogpeppe1 , that eliminates the common reason for phantom deps [16:02] sinzui: what do you mean by "importing a non-master branch" ? [16:03] dimitern, rogpeppe1 : Go checks out the master branch and gets its deps. Even when we ask for a non-master branch which has different deps, Go will leave the unwanted deps behind [16:05] sinzui: ah, so that'll be the reason this has broken [16:05] sinzui: because tip has dependencies that before-tip doesn't [16:06] okay. [16:07] rogpeppe1, dimitern 1 fix might be to change the build scripts to remove golang.org/x/crypto. I will consult with mgz_ [16:07] sinzui: yeah, ISTR some hack we had to get around this kind of problem [16:07] sinzui: but i can't remember what the official way to do this was [16:09] rogpeppe1, mgz_ pushed a change to a master branch I think. This case is different though. [16:10] sinzui: what we do is we don't use go get at all AFAIR [16:10] yeah, I can hackit out [16:10] we kind of have to use go get in some capacity [16:11] godeps doesn't implement branch/clone [16:13] why are unwanted dependencies a problem? [16:14] I can see missing dependencies, but unwanted should just be garbage on disk that we ignore [16:15] natefinch: we package this stuff, and also don't get great feedback from go about what actually goes into the binaries [16:17] so, maybe some new random github package we downloaded doesn't actually end up in the binary... but that does need asserting for licence/security raisins [16:21] it would be a pain to have to do an emergency security release because of a bug in a package that we're not actually using... [16:21] natefinch: it's good to check that we don't have unwanted deps because it's easy to omit deps from dependencies.tsv [16:22] rogpeppe1: that's true... but the way to do that should be to check that godeps -f produces the same output as dependencies.tsv ... that could also be what we use to determine the files to package [16:23] natefinch: unfortunately it won't [16:23] natefinch: because i haven't come up with a nice way of including windows deps in godeps output yet [16:23] natefinch: i will, but it's more work that i originally thought [16:24] rogpeppe1: oh right... dang [16:25] rogpeppe1: I wonder if the answer is just to switch to godep.... vendor the dependencies, then there's no question about keeping things in sync. === kadams54 is now known as kadams54-away [16:44] natefinch: that may well be a reasonable thing to do [16:51] dimitern, could the network fix joyent need a separate change for precise. I see the same kind of log error in cloud-init for precise as last week and the week before [16:55] sinzui, the one menno did? [16:55] dimitern, yes [16:56] r=me mgz_ . Can you merge and deliver it to unblock dimitern [16:57] sinzui, unlikely, might be intermittent [16:58] sinzui, menno's fix is not precise-specific, but then again if what joyent call a "precise image" is very different from the CPC images.. [16:59] dimitern, I am going to re-run tests again to capture logs and hope that trusty repeatedly passes [16:59] sinzui, +1 [17:00] sinzui: sure thing [17:05] sinzui: done - I only pulled the rev in on the juju-core-slave atm as the update all script barfs on an unknown 10. address for me - doesn't seem we have all of them in the .ssh/config on master somwhow? [17:05] :/ [17:06] mgz_, ssh and pull tip. I need to rethink the ssh/config rules for or private machines [17:08] hm, could I run in from the jenkins master isntead of locally? [17:15] natefinch: want another puzzle [17:16] natefinch: ? [17:16] natefinch: given a cidr I need to calculate the last allocatable IP address, knowing that the *last one* is reserved [17:16] natefinch: this is what I have: http://pastebin.ubuntu.com/9530758/ [17:16] natefinch: (includes code to work out lowest allocatable one - the first four are reserved too) [17:18] natefinch: I'm sure there must be a better way... [17:19] mgz_, \o/ ta! [17:19] a quick question about FormatSmart in juju/cmd - if I pass it a struct, is it supposed to delegate the marshalling to FormatYaml or return an error? [17:20] tasdomas, that's an excellent question - I was poking into it earlier today, let me check.. [17:20] dimitern, the comments on FormatSmart indicate that it should delegate a struct to FormatYaml [17:20] dimitern, but it seems to me that the default: case in the switch makes that impossible [17:20] tasdomas, yes it appears so [17:21] tasdomas, you refer to the last 3 empty cases? [17:22] tasdomas, and the default as well [17:22] dimitern, https://github.com/juju/cmd/blob/master/output.go#L75 [17:22] dimitern, yes [17:22] tasdomas, looking at the code invokes a WTF in me [17:23] voidspace: not sure I understand exactly what you're trying to do... can you give me an example? [17:23] dimitern, I was trying to use the smart formatter in a side project and passing it a struct returns an error [17:23] tasdomas, well.. I wouldn't recommend using this for anything [17:23] dimitern, heh, thanks for the recommendation [17:23] tasdomas, it's a (weak) attempt to make the output more pyjuju compatible [17:24] tasdomas, but it's neither well tested nor anyone cares too much it seems [17:24] tasdomas, I'd even say this deserves a bug report [17:24] dimitern, I see [17:25] natefinch: when we get a subnet from ec2 the last ip address is reserved [17:25] dimitern, I'll probably submit a pull request for it [17:25] natefinch: given the subnet in CIDR format I need to know what is the highest *allocatable* IP address [17:25] tasdomas, that'll be awesome, thanks! [17:26] natefinch: so, I take the "zeros" portion of the netmask, turn them to ones and OR it with the start IP address of the CIDR [17:27] natefinch: that gives me the last IP address, from which I subtract one to calculate the last *allocatable* IP address [17:28] voidspace: ok, so like if you get 123.123.123.0, then 123.123.123.255 is the "reserved" address, and .254 is the last allocatable one? [17:28] voidspace: sorry, my networking skills are *really* rusty [17:28] natefinch: correct [17:29] natefinch: a CIDR (subnet block) is an IP address plus netmask [17:30] natefinch: I believe my bit twiddling is correct, just not terribly elegant [17:31] natefinch: also going via a float (math.Pow) is pretty awful [17:31] natefinch: is there syntax for an integer power operation? [17:31] voidspace: math.pow IIRC [17:32] natefinch: that's float [17:32] natefinch: which I'm using currently [17:33] voidspace: just cast back and forth unless you think you'll run off the top of float64 [17:33] natefinch: highMask := uint32(math.Pow(2, float64(zeros))) - 1 [17:33] yuck :-) [17:33] yep [17:34] somebody might have made a copy of the package for integers [17:41] OCR PTAL : Fixes Go 1.4 vet error that blocks pre-push hook: (got approval, just looking for senior reviewer sign off) http://reviews.vapour.ws/r/630/ [17:45] jw4: FYI we shouldn't be building with 1.4.... though if we're at still backwards compatible with 1.2, that's fine, I guess. [17:46] natefinch: I see - I figured its fine to develop in 1.4 assuming that the CI tests are all running in 1.2.1 or whatever the supported version is [17:47] jw4: yeah, like I said, it's fine, but I think it does break some tests. [17:48] natefinch: Interesting. I'm pretty sure we found and fixed some tests that were broken by 1.3, which was a good thing. [17:52] jw4: it was something about our version of deep equals needing a different implementation in 1.4 or something... not actually a test failing, but something in our test frameworks not working correctly. IIRC Rogpeppe was the one who wrote the code [17:53] natefinch: I see. I'm guessing we're not moving to 1.4 (or later) until our next LTS version of Ubuntu? [17:54] jw4: or until it gets backported to Trusty. I'm not 100% certainly on all the ins and outs of Ubuntu packaging... but yes, Ubuntu is the limiting factor in one way or another [17:55] natefinch: cool [18:17] are we still blocked? [18:21] voidspace: yep [18:22] voidspace: http://goo.gl/4zd1e9 (shortened because the original is so long) [18:24] jw4: thanks [18:24] jw4: I've saved the bookmark this time :-) [18:24] lol [18:45] right, g'night all [18:45] see you tomorrow [18:47] fwereade: ping === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [20:07] sinzui: ci status? [20:07] thumper, We think we have a working rev. [20:07] sinzui: seems that both critical bugs are fix committed [20:07] \o/ [20:07] thumper, we are retesting to show that we didn't get lucky [20:08] kk [20:08] thumper: hey thank you for reviewing my branch [20:09] katco: np, was a mix of RB and github reviews, as the github diff handles moves much better [20:09] thumper: oh... i didn't even check gh; do i need to look there, or you were just using that as a tool? [20:09] katco: no, all comments are on rb [20:10] thumper: ah cool [20:11] thumper: thanks for aggregating them for me. i responded to all of your comments. please lmk if you disagree with anything (few questions in there too) [20:11] kk [20:17] sinzui: your comments on bug 1401130 indicate that the problem isn't fixed yet. is that right? [20:17] Bug #1401130: Joyent instances sometimes can't communicate via the internal network

[20:17] menn0, don't panic [20:17] menn0, The bug has always been about 1.20 and beta4 pass, alpah1 does not. 1.20 was failing about the time of the ci tests. [20:19] menn0, perrito666 and i have been doing repetitive deploys with 1.20, beta4, and alpha1. We have no failures for beta4, 1 failure for 1.20, and *no* failures for alpha1 so far. I and starting the last test to remove the regressions [20:20] sinzui: tx [20:20] sinzui: ok [20:20] sinzui, perrito666: has the joyent routing fix been backported to 1.21? [20:21] menn0, no, 1.21 never failed the tests [20:21] menn0: not that I am aware of it [20:21] menn0, I am not against backporting. I want dimiter's backport first though [20:23] sinzui: the routing fix is tiny and will be trivial to backport [20:23] menn0, okay, thank you [20:23] +1 to menn0 backporting his fix one cannot always be too sure [20:23] sinzui: I really do think that it's just luck that 1.21 has been passing [20:24] sinzui: master hasn't been passing because of that and this other issue [20:24] sinzui: where the deploy command fails [20:24] menn0, menn0 Its been a good streak given the number of bundles and release tests we did during the last two weeks [20:25] sinzui: indeed. that I can't quite understand given how easily I ran into the problem with 1.21 when testing manually [20:26] sinzui: I've been meaning to ask... with these deploy tests it looks like the Juju binary is pulled from a deb created elsewhere (I presume another jenkins job) [20:27] sinzui: how sure can we be that the deb matches the rev we think we're testing? === kadams54 is now known as kadams54-away [20:28] menn0, if you expand the listing of successes, you can see joyent has been partularly bad recent http://juju-ci.vapour.ws:8080/view/Cloud%20Health/job/test-cloud-joyent/ [20:30] menn0, The cloud jobs require a binary built by the publishing job. Each job downloads the deb that matches the hosts arch. many machines don't have juju installed. those that do can only have juju stable, and the log of the test would show the wrong version during bootstrap [20:31] menn0, you can see that the when destroy-env fails, we fallback to the stable juju to call destroy-environment --force [20:31] sinzui: ok [20:32] sinzui: my concern is that the tests pull the "last successful" build for the arch from revision-publish but how does the job know what revision that build was built from and whether it matches what the deploy test thinks it's testing? [20:33] sinzui: I'm not saying it doesn't work. I would just like to understand how it works :) [20:34] meno Those job cannot run of publish-revision fails. CI exits early and the other jobs are all left in pending [20:36] menn0, CI has a requirements chain. Jenkin's crap UI corrupts this stanza, which is the configuration of the job [20:36] [ci-director] [20:36] group-name: tests [20:36] requires: publish-revision [20:36] failure-threshold: 2 [20:36] vote: true [20:36] tags: subjects=substrate,CPC function=deploy substrate=joyent arch=amd64 series=precise [20:38] right, got it. so it's ci-director plugin that does the dependencies between jobs. I hadn't noticed that stuff before. [20:39] sinzui: thanks for the explanation [20:39] thumper: ping [20:46] ericsnow, wwitzel3: can you guys update this doc with how things are going? [20:47] natefinch: what doc? [20:47] https://docs.google.com/a/canonical.com/document/d/1eqDC5GwcLor1dpl8Wg3nYZw9xHuIqdxXXJEeIRJ883w/edit [20:49] natefinch: can't edit [20:49] ericsnow: reload [20:52] natefinch: updated [20:53] ericsnow: thanks. Obviously feel free to edit bullet points to fit whatever the actual tasks are etc. Just want that doc to be up to date since The Powers That Be are looking at it (and I just realized I'd never shown it to you and Wayne ;) [20:53] natefinch: got it === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1402826 [21:23] natefinch, thumper I think CI will bless master, but abentley found a regression when in the new weekly tests we added. We need someone look look into bug 1402826 [21:23] Bug #1402826: 1.21 cannot "add-machine lxc" to 1.18.1

[21:50]