[00:17] thumper: next one (small): http://reviews.vapour.ws/r/5112/ [00:21] menn0: re: the conversation we had at standup [00:29] redir: sorry, network dropped [00:30] menn0: increasing the timeout, i'm having trouble finding the place to make that change [00:31] wallyworld: meeting timeout:) [00:32] redir: yeah, sorry, network dropped out [00:32] i think we had finished? [00:32] sure [00:32] I've got enough rope... [00:41] davechen1y: I was thinking that testWatcher.NumDeltas should be changed to take a timeout [00:41] davechen1y: and then change the 2 calls to it so that AssertNoChanges passes ShortWait and AssertChanges passes LongWait [00:41] There are millions of AssertNoChanges [00:42] and something about a stringsWatcher [00:42] davechen1y: the 2 places where NumDeltas is called [00:42] is that a test mock ? or the usual strings watcher [00:42] oh creap [00:42] https://bugs.launchpad.net/juju-core/+bug/1594578 [00:42] testWatcher.AssertNoChange and [00:42] Bug #1594578: state: test failure in race build [00:42] I was looking at the wrong bug [00:42] sorry, it should make sense now [00:43] davechen1y: looks to be a special mock/fake for these tests [00:43] it's all a bit ropey [00:44] davechen1y: the whole NumDeltas thing a bit crap... maybe there's a better way. [01:11] thumper: does maas 1.9 support arbitary tags on machines? maas 2 does right - that tag slice on gomaasapi/machine can have anything added to it we want during StartInstance() ? [01:11] wallyworld: no [01:11] the tag slice at the moment is maas tags [01:11] not user defined tags [01:11] I don't think gomaasapi exposes the user tags yet [01:12] damn ok [01:12] was hoping to add controller uui etc [01:12] nope [01:12] sorry [01:12] ok :-( [01:12] still need that provider-state file then [01:12] for now [01:13] was hoping to avoid an upgrade step [01:19] menn0: wow, AssertNoChange is nuts [01:19] start sync, look, and hope that nothing changed [01:19] so you dn't know if you looked to quickly [01:19] or if nothing happened [01:19] or something else went wrong [01:43] menn0: you got a minute? [01:43] or thumper [01:43] got a migration question [02:07] wallyworld: hi, yep [02:07] menn0: quick hangout? [02:08] wallyworld: sure [02:08] https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand [02:08] axw: ^^^ [02:19] Bug #1594290 changed: Duplicate key error on juju.txns.stash creating model

[02:22] menn0: thanks for your suggetiosn [02:23] i have PR that makes that test a little less crackful [02:24] davechen1y: awesome. let me know if you need a review. [02:44] menn0, wallyworld: trivial fix http://reviews.vapour.ws/r/5114/ [02:44] ok [02:45] thumper: double ship it [02:45] thumper: jeez, what a bad assert [02:45] cheers [02:46] I'll just backport to 1.25 [02:55] who wants to review some windows code? Fun for young and old! https://github.com/natefinch/npipe/pull/21 [02:56] (also short and easy) [03:00] menn0: allwatcher_internal_test.go:3106: c.Assert(len(d), gc.Equals, 0) [03:00] ... obtained int = 1 [03:00] ... expected int = 0 [03:00] yay [03:00] i fixed it [03:00] now the other test fails ... [03:00] fml [03:01] davechen1y: progress! ;-) [03:03] sorta [03:04] also, witness the brilliance of gocheck [03:04] http://paste.ubuntu.com/17630317/ [03:04] which of the six calls to AssertNoChange on this page failed ? [03:04] there is a prize if you guess the correct one [03:05] 'cos I sure af don't know [03:07] axw: oh yeah, also, there's currently no exposed method to get the name of the model's cloud that i can see; there's st.Cloud() but that doesn't expose the nme from the cloudDoc [03:07] did we want to use a bespoke struct which maybe embeds cloud.Cloud [03:08] wallyworld: State.ControllerInfo() has it [03:08] ah rightio [03:08] wallyworld: I think we'll end up adding it to Model tho [03:08] i thiknk so yeah [03:08] a new method, CloudName() string [03:08] i'll stick with what we have for now [03:08] davechen1y: it's not fair to blame bad tests on the framework. It would be just as bad with the default test infrastructure [03:08] can iterte [03:09] natefinch: false [03:10] t.Errorf(...) // will print this exact line [03:10] it does mean you cannot write test helpers [03:10] but that was something that rob pike hates [03:10] for reasons that I don't understand [03:11] my general approach to tests is that DRY is an extreme anti-pattern in tests. You want the code right in your face as much as possible. [03:13] * thumper looks at how to reapply a diff [03:13] this kind of failure message is one reason why I hate table driven tests. You have to be really really careful about how you code them, or they are super confusing when they fail. The latest addition to the go test framework makes that significantly better, but not perfect. [03:18] thumper: FUK FUK FUK [03:18] now i've broken the test the other way [03:18] heh [03:18] AssertNoChange now randomly reports some bullshit results [03:23] oops [03:25] this is like when you're working on the car [03:25] you;ve got the engine disconnected from the transmission and you discover you need a part from the store [03:25] and you've just taken your car apart [03:28] davechen1y: http://www.dailymotion.com/video/x2gp98t [03:29] wallyworld: http://reviews.vapour.ws/r/5118/ serialization tag reintroduction [03:29] wallyworld: what did I get wrong last time? [03:29] storagesize [03:30] wallyworld: can I get you to cast your eyes over the diff [03:30] and just open issues for all wrong bits? [03:30] yep looking [03:30] I'll fix before landing [03:30] cheers [03:30] thumper: diff looks like you got branches mixed up [03:31] wat? [03:31] * thumper looks [03:31] hmm maybe not [03:31] just saw the first few changes [03:31] looked unrelated [03:31] no [03:31] there were issues where the api was doing bad things [03:31] like using its own structs [03:31] or passing through state structures [03:32] gawd [03:32] wallyworld: also, if testing was inside a goroutine [03:32] I ended up changing the Asserts for Checks [03:33] because you souldn't assert in a go routine [03:33] yay, good catch [03:33] full test suite run is running locally for that branch [03:33] making my fan howl [03:43] wallyworld: so as fwereade pointed out in a review yesterday, it's a bug that the client side watchers (in api/watcher) could still be doing stuff (like calling the Stop API for a watcher) after the client side watcher has indicated it is done [03:44] wallyworld: I think I know how to fix it (using catacombs) but it's a non-trivial amount of work [03:44] menn0: which bug? sorry lack context [03:47] wallyworld: http://reviews.vapour.ws/r/5106/ the remaining open issue [03:48] wallyworld: the test is even worse than it needs to be because it the Stop call happens in a goroutine that might still be running after the client side watcher is dead [03:49] menn0: i reckon land it and fix later, it's not like this PR introduces the bug [03:49] the problem is the way commonWatcher (api/watcher) integrates with the specific watcher types [03:50] wallyworld: i've already landed the PR ... just wondering about fixing the problem in a separate PR [03:50] I might just do Will's suggestion and have the worker take a watcher constructor [03:50] and file a bug about the broken watcher behaviour [03:50] sgtm, incremental progress [03:50] kk [03:51] wallyworld: thanks for being a rubber duck :) [03:51] quack quack [03:55] anyone care to rubberstamp a deps update that fixes a blocking bug? http://reviews.vapour.ws/r/5119/diff/# [03:56] natefinch: lgtm [03:56] thumper: i marked the typo in the pr [04:06] wallyworld: cool [04:16] thumper: menn0 https://github.com/juju/juju/pull/5676 [04:16] took the easy way out [04:17] davechen1y: looking [04:17] davechen1y: not sure if that's a good idea [04:17] davechen1y: that makes the testWatcher.AssertNoChange calls take 10s right? [04:18] if the code is behaving correctly and there is in fact no change [04:18] davechen1y: that's why I was suggesting that there might need to be a more invasive change [04:19] davechen1y: maybe NumDeltas should go away, and AssertNoChange and AssertChange should have independent implementations [04:21] menn0: i tried that [04:21] it jsut make a mess [04:21] i did that [04:21] menn0: http://paste.ubuntu.com/17632486/ [04:21] now AssertNoChange fails reliably ... :( [04:25] davechen1y: hmmm [04:25] davechen1y: i'm not exactly sure what's happening there [04:25] davechen1y: is len(d) > 0 when a change is detected? [04:25] (where d is the actual deltas) [04:26] yup [04:26] if there is no change, then nothing should be deliverd on tw.delta [04:33] davechen1y: could it be that there's deltas not being completely consumed from the previous change? [04:34] davechen1y: FWIW I'm pretty sure AssertChanges in your diff should be using LongWait, not ShortWait [04:34] menn0: this is all rubbish [04:34] make a chage [04:34] wait to see if anything happened [04:35] maybe something happened, maybe didn't wait long enough [04:35] reverse the logic for _not_ expecting a change [04:35] there is no synchonisation, only waiting [04:35] i'm amazed this works at all [04:35] welcome to watchers [04:37] what a bunch of bollocks [05:07] Bug #1594663 opened: Client side watchers may still be active when they report themselves as dead

[05:07] Bug #1594665 opened: reboot-executor is missing from the list of workers

[05:31] thumper or wallyworld : addresses an issue fwereade raised in a previous PR: http://reviews.vapour.ws/r/5106/ [05:31] ok [05:34] wallyworld: sorry, wrong PR: http://reviews.vapour.ws/r/5121/ [05:34] tis ok, found it already [05:35] wallyworld: at least it was the one where fwereade raised the issue :) [05:38] menn0: i just had a quibble / question about end-end test coverage, but it does look far less complicated [05:39] wallyworld: and I don't think we really lost any coverage here... the API call was fake before [05:39] wallyworld: it's just avoiding testing stuff that is actually in another package and tested there [05:40] rightio [05:40] wallyworld: agreed on the end-to-end test. there will be a feature tests added, and CI tests of course, as everything comes together [05:40] sgtm [05:40] wallyworld: veebers is on the case with the CI test [05:40] \o/ [06:21] menn0: this is terrible [07:14] menn0: thumper https://github.com/juju/juju/pull/5678 [07:14] attempt #2 [07:38] dimitern: want to skip 1:1? I want to go through some of the things we discussed with jay last night before standup. [07:38] frobware: sure, np [07:39] frobware: I've picked up bug 1594580 anyway [07:39] Bug #1594580: lxd container invalid parent device name

[07:39] dimitern: one useful tidbit is: sudo cat /proc/net/bonding/bond0 [07:39] dimitern: the info in there (and must run as root) tells you whether the LACP setup actually happened. [07:40] frobware: that's useful to know indeed! [07:40] davechen1y: reviewed [07:41] frobware: I've decided against trying to set up bonding on the nucs for now [07:41] dimitern: makes sense in absence of h/w :) [07:42] frobware: yeah :) [07:42] dimitern: I woild not suggest the nuc I bought - too slow and the lack of AMT is a pain [07:44] frobware: what cpu did it have? dual-core celeron? [07:44] dimitern: yep, though it may have threads, so 4. [07:44] frobware: but still.. celeron :) [07:53] menn0: thanks, i'll try to integrate some more "wait this long, max" logic [07:55] davechen1y: cool [08:05] wallyworld: this change I'm working on is excruciating, and unlikely to be ready by beta10. I think I'll take a break tomorrow and fix some of the bugs raised on beta9 [08:06] and when I say "unlikely", I mean "almost certainly not" === Spads_ is now known as Spads [08:16] axw: is this json for gce? [08:17] anastasiamac: not working on that yet, will probably look tomorrow [08:17] anastasiamac: hve been looking at some fundamental changes to model config / cloud / credential separation [08:17] axw: k. thnx \o/ [08:56] Bug #1594720 opened: 2.0 b9: Fail to deploy LXD container in restricted network [09:02] dimitern: voidspace: standup [09:02] ? [09:02] sorry, omw [09:38] dimitern, voidspace: hmm - why didn't this PR get a review created? Is it because I ended with a comment in parens? https://github.com/juju/juju/pull/5679 [09:39] babbageclunk: no idea... [09:39] babbageclunk: ask ericsnow when he comes online [09:39] babbageclunk: every now and then this happens [09:39] voidspace: ugh, that's ages away [09:39] babbageclunk: yep [09:40] voidspace: I'll try a little chicken-slaughtering to see if that helps. [09:42] voidspace: Yeah! I'm the boss of computers! [09:44] voidspace: I mean, it could just have been a coincidence, but that superstition is sticking from now on! [09:47] morning [09:51] dimitern, voidspace, frobware: reviews welcomed! http://reviews.vapour.ws/r/5123 [09:51] babbageclunk: I'll have a look in a bit [09:51] dimitern: cool thanks - no big rush [10:18] niemeyer1: ping? [10:21] babbageclunk: heh, I didn't realise chicken sacrifices helped [10:21] babbageclunk: I don't have any chickens but I do have two children, maybe I could spare one of them... [10:22] I think children are worth between 5-10 chickens. [10:24] babbageclunk: so worth waiting for a really serious bug [10:24] babbageclunk: hmmm... I wonder if sacrificing both would fix our issues with /en/n/i [10:25] might actually be worth it... [10:25] we can always grow some more [10:25] voidspace: tsk [11:28] voidspace: well, no chickens or children needed. A sleep of 0.5s between ifdown/up seems to cure it. \o/ [11:33] frobware: yay! [11:33] frobware: that's better than a 10min reboot. [11:33] babbageclunk: give or take, about 10mins. :) [11:34] babbageclunk: I cut & paste the commands we run and ran them "by hand" in the shell.. it was then I noticed that it worked. Put the same commands back in a shell script and it all fails. [12:02] frobware: dumb computers doing stuff too fast for themselves. [12:03] babbageclunk: agreed. if we would all slow down we'd get there faster :P [12:49] frobware: that's great [13:51] Bug #1571053 opened: container networking lxd 'invalid parent device'

[13:53] cherylj: have a bug you'd like me to work on? [13:55] natefinch: Of course! Want to take a look at bug 1593299 ? [13:55] Bug #1593299: HA recovery fails in azure

[13:56] cherylj: I figured that might be your answer, being the only blocker not in progress. Sure thing. [13:56] I'm sorry I'm so predictable [13:56] ;) [13:56] :) [13:57] oh azure, that special flower... [14:24] cherylj: hi, do you know more or less when master will be unblocked so that I can merge a couple of little contributions I have? [14:25] frankban: if you send me the PRs, I'll evaluate and merge it for you [14:25] cherylj: http://reviews.vapour.ws/r/4936/ and http://reviews.vapour.ws/r/5124/ (though the latter could wait for another review) [14:30] Bug #1571053 changed: container networking lxd 'invalid parent device'

[14:31] frobware, just need a few minutes for a cup of coffee [14:31] brt [14:40] frobware, voidspace: a tiny-ish review fixing bug 1594590, please take a look - http://reviews.vapour.ws/r/5125/ [14:40] Bug #1594590: [needs packaging] arc-theme [14:40] oops not that one [14:41] dimitern: I don't believe you ever produce small reviews [14:41] but I'm willing to be surprised [14:41] voidspace: :) you might be surprised [14:41] let's try again mup.. bug 1594580 [14:42] Bug #1594580: lxd container invalid parent device name

[14:43] frankban: I kicked off the merge for the first PR. Let me know when you get another review for the second [14:44] OMG https://jujucharms.com/docs/devel/help-azure [14:45] sudo apt-get install -y nodejs-legacy npm [14:45] WTF [14:46] cherylj: ty! [14:46] natefinch: you can grab the CI creds and not have to do all that [14:47] dimitern: LGTM [14:47] cherylj: thanks... I have azure set up from forever ago, so in theory, I just need to grab those values off the website or something... it's just... do we really expect someone to follow this 15 (yes, I counted) step process [14:49] voidspace: cheers! [14:50] perrito666: could you please take a look at replies at http://reviews.vapour.ws/r/5124/ ? what do you think? [14:51] frankban: I see, well we can always change if we need something else in the future, as roger says [14:52] perrito666: so can I go ahead and ship it? [14:53] frankban: you have a shipit from roger :p he just forgot to click the button [14:53] frankban: is master unlocked? [14:53] perrito666: no, I'll handle that, I'd like to have a ship it from a core dev [14:56] frankban: sure, ship it [14:56] (I added the shipit to the pr) [14:57] perrito666: thanks [15:03] Bug #1594855 opened: MAAS provider bridge script on trusty does not handle LACP bonds

[15:06] ericsnow: standup time [15:10] natefinch: would you be able to port your fix for bug 1581157 to 1.25? [15:10] Bug #1581157: github.com/juju/juju/cmd/jujud test timeout on windows

[15:13] cherylj: hey, re 1.25.6 - still planned to ship tomorrow? [15:13] cherylj: yeah. it's just a deps change [15:14] thanks, natefinch [15:14] dimitern: I don't think it'll be tomorrow [15:14] dimitern: but we should try for this week [15:14] cherylj: ok, cheers [15:14] dimitern: are you asking for bug 1594855? [15:14] Bug #1594855: MAAS provider bridge script on trusty does not handle LACP bonds

[15:14] cherylj: yeah, exactly :) [15:15] cherylj: it's affecting a customer [15:15] Bug #1593838 opened: juju beta9 does not support "lxc" notation in bundles

[15:15] dimitern: k, do you have an ETA on the fix? [15:16] cherylj: likely tomorrow - frobware is testing a fix already [15:17] cherylj: we've (more or less) established the root cause at least [15:17] ok, cool [15:17] dimitern: did someone ask you about bug 1590598 too? [15:17] Bug #1590598: ipv6 interfaces configured on a machine (in maas) are not added to lxc containers deployed to that machine

[15:17] cherylj: nope, looking.. [15:18] dimitern: you had a comment in there that "we'll address this soon", and wanted to know if this was still on your radar [15:18] cherylj: ah, I remember this one [15:18] cherylj: yeah, it's a known limitation atm [15:18] dimitern: is it something we want to commit to for 2.0? or does it need more time and should be deferred to 2.1? [15:19] cherylj: I'd say 'good to have for 2.0', but realistically - 2.1 [15:20] dimitern: is it large enough that it needs to be sized and budgeted for (headcount wise)? [15:20] cherylj: it's not inherently difficult, there are more serious issues we're focusing on first [15:20] dimitern: k, thanks [15:21]