[02:00] * thumper shudders as he builds 1.25 for some testing [04:51] babbageclunk: next one https://github.com/juju/juju/pull/8573 [04:51] wallyworld: or you could... ^^ [04:51] * thumper goes to make a coffee [04:51] yeah, share the love! [04:51] * wallyworld gets coffee and then looks [04:51] babbageclunk: actually, wanna chat briefly? [04:52] i hear you've living the dream [04:55] wallyworld: yes please! [04:55] in standup? [05:00] so lonely [05:03] wallyworld: actually I dropped out because it screws up the timing in the test [06:06] wallyworld: thumper: PTAL https://github.com/juju/juju/pull/8574 [06:13] thumper: ok it gets weirder - it's not the manifolds, because they're never called (jujuconnsuite runs a minimal set of workers, but it doesn't run a dep engine). So it's actually something that gets imported by the worker/raft package (or worker/raft/rafttest) [06:13] on the way to working it out now. [06:14] thumper: also https://github.com/juju/juju/pull/8575 for deprecation on the flag [06:16] babbageclunk: that's weird [06:17] anastasiamac: check failed for first PR [06:17] thumper: yes, looking [06:18] thumper: but doubt it's me - i changed only tests, and that should not have effected featuretets pkg at all.. mayb intermittent... [06:19] babbageclunk: oh sorry, missed ping [06:19] wallyworld: I also updated presence PR [06:20] looking. stupid quassel doesn't beep at me anymore [06:22] wallyworld: my quassel is struggling to beep too [06:22] yeah, so i miss a lot of pings :-( [06:22] especially when i'm knee deep in code etc [06:22] why aren't you neck deep? [06:22] what is wrong with you? [06:23] wallyworld: I haven't squished commits yet so you can review the changes more easily [06:23] wallyworld: I'll squish before getting the bot to merge [06:23] ty [06:24] i need to start doing that too [06:24] I'm done for the day [06:25] thumper: lgtm but from diff it appears there could be some newlines between methods in interface missing [06:25] wallyworld: I've not got newlines between every call [06:25] as I've grouped them [06:26] do we really need newlines? [06:26] i think that's the expected way to do it [06:27] IIANM [06:27] YMMV [06:27] FFS [06:27] fine [06:29] wallyworld: some blank lines just for you [06:29] \o/ ty, still lgtm, land that sucker [06:30] you didn't approve [06:30] oh, I see you did earlier [06:30] thanks [06:30] np [06:31] * thumper squishes and pushes [06:31] oh no!!! [06:31] I had a mouthful of coffee left in my cup [06:31] and it is now cold [06:31] :( === frankban|afk is now known as frankban [09:16] jam: As mentioned. [09:16] PR for supplying image metadata url and stream to containers: https://github.com/juju/juju/pull/8578 === salmankhan1 is now known as salmankhan [10:16] manadart: reviewed [10:19] jam: Ta. [11:19] manadart: I think I figured out why you can't use TearDownTest with gomock [11:20] the gc.C that is passed into TearDownTest is not the same object as the one passed into SetUpTest [11:20] manadart: and you probably can't assume it is the same as the one during the test itself. :( [11:23] manadart: I'm not positive about it. but if I just put a "c.Fail" in TearDownTest then I at least get "test fixture has paniced" [11:23] which would at least 'fail' the test [11:24] manadart: I *definitely* see that the object passed into SetUpTest is not the same object as passed into the Test itself. [11:25] manadart: interestingly, if the test itself fails an assertion *during* the test, then it will report whatever the SetUpTest object got as failure messages [11:25] but it can't fail on its own during TearDown. I'm a bit surprised at that, but it is what I'm seeing :( [11:25] jam: That explains the behaviour I saw when testing it. If I panic'd the test I could see some of the satisfied/unsatisfied calls reporting, but not when running finish in teardown. [11:28] jam: One option might be to write a TestReporter implementation, instantiate as a member of the suite in SetupTest, pass it to MockController. Then in TeardownTest we always know what we are getting and can Finish. [11:29] manadart: well potentially a TestReporter that is a thunk, and then you call "SetThunk" in each place. but I don't think it would really give the behavior you want [11:29] manadart: specifically, failures in assertions will get "Fixture has paniced()" rather than just treating it as a failed test. [11:30] jam: Yes I thought "oh, but wait" after I typed that :) [12:33] balloons: can you hear me? === freyes__ is now known as freyes === frankban is now known as frankban|afk === iatrou_ is now known as iatrou === icey_ is now known as icey === vern_ is now known as vern [22:10] thumper or wallyworld: could you please review this? https://github.com/juju/juju/pull/8571 Sorted out that weird failure. [22:10] babbageclunk: ack [22:10] babbageclunk: what was it? [22:10] sure soon, otp for a bit [22:10] thanks! [22:11] babbageclunk: what is your response to jam's question? [22:12] It was the import thing - importing the FSM from rafttest meant that some test fixture stuff came in too, and something in that lot did (something I'm not sure what) at package init time that meant that the hook commands ran slower. [22:12] Would have been easier to find if golang allowed unused imports I think. [22:12] thumper: not sure - need to think about it more carefully. [22:13] babbageclunk: so the fix was what? [22:13] move the FSM out of rafttest into worker/raft. [22:16] short review anyone? https://github.com/juju/juju/pull/8582 [22:16] balloons: ^^ [22:16] :-) [22:18] :-) awesome heather! [22:19] wallyworld, thumper tiny addition to the charmrepo.v3 change [22:19] https://github.com/juju/charmrepo/pull/125 [22:19] * wallyworld still otp :-( [22:19] ack [22:24] hml: lgtm [22:28] veebers: ty [22:38] veebers: build's failing on yours? [22:38] wpk: why is timing a big issue here? with the interfaces.py? [22:40] wpk: ifdown used to be before the interfaces.py was called [22:42] babbageclunk: ah as per comment, test failure as charmstore.v5 still deps on charmrepo.v2 and thus fails. I could add charmrepo.v2 to charmrepo.v3 deps but that's mucky :-) Once this lands I'll propose a PR for charmstore.v5 (my branch will currently be the only thing depping on charmrepo.v3 right now) [22:42] hml: the main concern is to wait with anything that's hard to revert for as long as possible, we've seen weird failure modes and IMHO it's impossible to avoid them all, but we could do as much as we can to 1. avoid them 2. make the machine boot if we f.up [22:43] veebers: oh sorry - didn't see that! [22:44] hah I may have made it after you looked at the PR ^_^ [22:46] wpk, veebers, balloons: will look at changing interfaces.py instead in the AM [22:47] that's my story and I'm sticking to it. [23:16] babbageclunk: anastasiamac: standup? [23:18] m standing m standing \o/