| blahdeblah | Morning! Any update on 2.2.2 release date? | 00:12 |
|---|---|---|
| axw | burton-aus externalreality: standup? | 00:32 |
| burton-aus | axw just in | 00:33 |
| axw | thumper: what are the blockers for 2.2.2? I think #1700451 should be | 00:46 |
| mup | Bug #1700451: Upgrade from 2.1.x to 2.2.1 blocked by missing Azure resources <canonical-is> <upgrade-juju> <juju:In Progress by axwalk> <https://launchpad.net/bugs/1700451> | 00:46 |
| axw | oh maybe there's tags... | 00:46 |
| axw | hm nope | 00:48 |
| babbageclunk | blahdeblah: not sure - thumper? | 01:01 |
| axw | babbageclunk: I don't understand why you've used that expression for the wait time in WaitAdvance. why not just use coretesting.ShortWait? | 01:07 |
| babbageclunk | axw: Hmm, I thought I had tried it but now I'm not sure. Hang on, I'm trying it again now. | 01:11 |
| axw | babbageclunk: that test was already pretty confusing | 01:13 |
| babbageclunk | axw: yeah - I tried rewriting it to be simpler, but it needs a test clock to be advanced (and so a goroutine) otherwise it just hangs. | 01:14 |
| axw | babbageclunk: I think we want to: WaitAdvance(<10ms, coretesting.ShortWait, 1), then show that listener.count is still zero, then WaitAdvance(enough-to-reach-10ms, coretesting.LongWait, 1) | 01:14 |
| axw | babbageclunk: there's a testing.AutoAdvancingClock that you could use, but it'll involve rewriting all the tests in that file to pass in a clock to testListener I think... or using an auto advancing clock in all the tests, which might not be better | 01:15 |
| axw | it starts getting a bit too closely tied to the implementation tho | 01:16 |
| babbageclunk | axw: Oh, just reread your question - I thought you were talking about the first argument to WaitAdvance, but you were talking about the second argument? The amount to advance the clock? | 01:19 |
| axw | babbageclunk: yes | 01:19 |
| axw | babbageclunk: no wait... | 01:20 |
| axw | babbageclunk: the amount of wall clock time to wait | 01:20 |
| babbageclunk | axw: ok, right. | 01:20 |
| axw | babbageclunk: (in the inner loop of WaitAvance) | 01:20 |
| babbageclunk | I'll try what you're suggesting. | 01:21 |
| babbageclunk | axw: No, if we advance the clock by short wait, it's over the min pause threshold, so there's a chance that the pause will complete, and the test fails with "pause returned too soon" | 01:30 |
| axw | babbageclunk: I don't understand that - teh amount of time waited by WaitAdvance is independent of the amount advanced? | 01:31 |
| babbageclunk | yes | 01:31 |
| babbageclunk | the first's wallclock time, the second is simulated time. | 01:32 |
| babbageclunk | They're two independent but confusing axes. | 01:33 |
| axw | babbageclunk: isn't it the other way around? https://github.com/juju/testing/blob/master/clock.go#L118 -- d is first, which is the amount of time we advance the clock (simulated time) | 01:33 |
| babbageclunk | axw: Gah, you're right! I had misread that. | 01:35 |
| axw | babbageclunk: :) I always have to check the order, never can remember | 01:35 |
| thumper | hey | 01:36 |
| * thumper looks | 01:36 | |
| babbageclunk | axw: That's why the results were so confusing when I was doing it. Ok, your way makes sense then. Trying it now. | 01:36 |
| thumper | axw: how is the separation of model upgrades from controller upgrades going? | 01:37 |
| axw | thumper: the upgrade bits are separated, I'm onto the next bit, which is blocking logins to the models before they're upgraded | 01:38 |
| thumper | axw: ok, cool | 01:38 |
| axw | thumper: and I've hit a snag, need to synchronise the controllers. prob won't be done till tomorrow now | 01:39 |
| thumper | axw: wouldn't it just be looking at the value in the model doc and blocking if not expected? | 01:40 |
| axw | thumper: sorta. only one controller machine gets an Environ (singular worker), so we either make them all get one, or use something other than the environ version to synchronise on. they all need to agree on a value to check for | 01:41 |
| axw | thumper: I'm leaning towards the latter atm, to avoid unintended uses of environs in multiple controller machines | 01:42 |
| thumper | axw: we are storing the environ version in the model doc though right? can't we synchronize on that? | 01:42 |
| axw | thumper: yes, but only after they've upgraded, and the ones that don't have the Environ don't know what version it'll go to | 01:43 |
| babbageclunk | axw: Thanks for the sanity checking! That is much clearer, I think. | 01:43 |
| axw | thumper: and we have to block them all until the upgrades are done | 01:43 |
| axw | babbageclunk: cool, np | 01:43 |
| thumper | axw: hmm... so just need to work out what to sync on then... | 01:44 |
| axw | thumper: I was just going to use the controller version | 01:44 |
| thumper | couldn't there just be a registry of expected environ versions based on provider that the apiserver has? | 01:45 |
| thumper | it won't change between controllers | 01:46 |
| axw | thumper: yeah, could do. I could just make the EnvironProvider return the upgrade ops / version. I'll look into that | 01:46 |
| thumper | as it will be fixed for any compiled code | 01:46 |
| axw | thumper: that should work alright. that's the easy bit anyway :) | 01:50 |
| * thumper nods | 01:55 | |
| axw | thumper: tech board? | 04:02 |
| thumper | coming | 04:02 |
| babbageclunk | thumper: If I want to add a new field to a uniter params struct, I guess that means adding a new version to the uniter API? | 04:12 |
| babbageclunk | thumper: or can I get away without that? | 04:12 |
| thumper | it depends | 04:13 |
| thumper | I know that the pyjuju library before would have issues if we changed things | 04:13 |
| babbageclunk | thumper: ok - I don't think it's hard to do anyway. | 04:19 |
| babbageclunk | axw: updated that test fix. Take another look if you get a moment? https://github.com/juju/juju/pull/7596 | 04:20 |
| axw | babbageclunk: just saw, and LGTMd | 04:20 |
| axw | babbageclunk: thanks | 04:20 |
| babbageclunk | thanks! | 04:25 |
| === frankban|afk is now known as frankban | ||
| rogpeppe | jam: hiya | 09:26 |
| rogpeppe | jam: there's a goose review here that you might want to take a look at https://github.com/go-goose/goose/pull/51 | 09:27 |
| jam | rogpeppe: looking | 10:49 |
| rogpeppe | jam: thanks | 10:49 |
| jam | rogpeppe: reviewed | 11:06 |
| rogpeppe | jam: tyvm | 11:06 |
| rogpeppe | jam: "I'm a little concerned that just dropping the ErrUnexpectedEOF may work for a particular client, but not for all." | 11:25 |
| rogpeppe | jam: do you mean for a particular server there? | 11:25 |
| rogpeppe | jam: BTW, do you know what version of Go we can assume for the swift code? | 11:31 |
| jam | rogpeppe: so looking up an etag and getting a read seeker seemed disconnected, so it seemed like you could call one without having the other. Further, do all Openstack implementations that we operate against support ETAG? | 11:32 |
| jam | rogpeppe: 'go version for swift code' ? Juju itself is I think 1.8 only now, are you wondering about other consumers of goose? | 11:33 |
| rogpeppe | jam: yeah, i'm wondering about other goose consumers | 11:33 |
| jam | rogpeppe: tbh I don't know other goose consumers. it isn't a project I've kept close ties with, or heard a lot of noise about people using it. | 11:36 |
| rogpeppe | jam: i would hope that all Openstack implementations support Etag as the API is derived from S3 and that supports it (also, the API docs describe it and don't say it's optional) | 11:37 |
| rogpeppe | jam: i suspect no-one else uses it. i'm going to assume Go1.8. | 11:37 |
| rogpeppe | jam: i guess it depends what semantics we expect from a file that changes underfoot (if a server doesn't support Etag and If-Match). I think that getting an error when reading the file is probably OK. | 11:38 |
| rogpeppe | jam: are you minded to approve the PR? | 11:55 |
| rogpeppe | jam: FWIW I'm planning on waiting for jrwren to approve it because he was the one that wrote the ErrUnexpectedEOF logic and might have some info we don't | 11:56 |
| rogpeppe | jam: here's another goose review for your delight and delectation - this one is a performance enhancement: https://github.com/go-goose/goose/pull/52 | 12:46 |
| === frankban is now known as frankban|afk | ||
| === tvansteenburgh1 is now known as tvansteenburgh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!