[01:09] wallyworld: would you please review https://github.com/juju/juju/pull/7100 some time today. the changes for remove-machine won't be far behind [01:09] sure [01:11] wallyworld: I've kept the apiserver changes in a separate commit, to make reviewing a bit easier [01:11] sgtm ty [01:50] axw: make sure to check out https://www.youtube.com/watch?v=tjp_JHSZCyA will have a blog post/email hopefully tomorrow as follow up [01:50] rick_h: okey dokey. otp, will watch afterwards [02:04] * axw brews a cup of tea and listens to rick_h's smooth radio voice [02:11] axw: sick burn when the guy's doing a video! ;) [02:11] babbageclunk: I'm just listening while doing other stuff! [02:11] axw: oh, right! [02:12] I have a habit of being unintentionally offensive :| [02:12] * rick_h winks at axw [02:13] axw: same. :( [02:14] whoa, matt's beard [02:20] wallyworld, axw: worked out my bug - taking the address of a loop variable so all the metadata settings had the same value. [02:20] ah, that old chesnut [02:20] that's bitten me before too [02:20] i reckon it's bloody stupid design by Go [02:22] wallyworld: is there a better way around it than making a new variable in the loop? [02:23] babbageclunk: depends on what you're doing. that's a common solution [02:23] babbageclunk: point me at code? [02:24] i usually make a new va rinside the loop [02:24] axw: I've seen the to.StringPtr in azure provider, but this is just one case so that's maybe overkill. [02:24] babbageclunk: yeah I think so [02:26] axw: it's herehttps://github.com/juju/juju/blob/develop/provider/gce/google/instance.go#L185 [02:26] axw: ...but in the new api version the value is a *string [02:26] (I mean, MetadataItems.Value is *string) [02:27] I see [02:27] babbageclunk: yeah, I'd just do (above): valueCopy := value, then &valueCopy [02:28] babbageclunk: if you're using a loop value in a function literal (not the case here obv), I'd give the function args and pass the value in [02:28] rather than just closing over the outer var [02:29] axw: yeah, that's how I'd handle the analogous problem in Python [02:40] rick_h: looks good! having prebaked dashboards will be useful [02:42] axw: yea, get an "opinionated" ootb thing going [02:43] rick_h: in terms of useful things, I'm not sure what else to add. maybe API request throughput? but it's probably only useful for debugging, rather than general health check [02:44] axw: yea, folks can turn on things when there's an issue but want to just do the basics for all folks ootb [02:44] * axw nods [02:46] axw: i had a few issues, see what you think [02:46] nothing that major [02:46] wallyworld: ok, thanks [02:47] wallyworld: huh, thought I renamed DestroyUnit to DestroyUnits. must've been thinking of the machines branch [02:47] no worries [02:50] wallyworld: the api/machinemanager changes weren't meant to be there, but ok if I leave them in and add tests in the follow up? they're not used yet anyway [02:50] axw: yeah, i figured as much :-) [03:27] wallyworld: Do you know how I could tell bootstrap to use a different network in GCE? [03:28] no :-( [03:28] hmm [03:29] --bin peraps [03:29] --bind [03:29] i think that may work? [03:29] babbageclunk: actually [03:29] --to [03:29] with a network placement directive [03:29] i remmeber now [03:30] wallyworld: so I can say bootstrap --to with-subnets? I'll try that. [03:30] i can't recall the exact syntax [03:30] it was in some release notes for 2.1 i think [03:32] wallyworld: seems to be doing something anyway [03:32] i'll see if i can find the release notes [03:37] babbageclunk: https://github.com/juju/juju/pull/6907 [03:37] it's in 2.2 [03:37] not released yet [03:37] wallyworld: cheers [03:44] wallyworld: d'oh, that's aws specific - I want it for gce. Not that surprising, I guess, given that we don't support subnets in gce yet. [03:44] babbageclunk: yeah, once subnets are implemented, it should work. i thought that's what you were testing :-) [03:47] wallyworld babbageclunk: if you're adding more stuff to apiserver/application for CMR, can you please add tests to application_unit_test.go, not application_test.go [03:47] ok [03:48] i didin't notice we had that even [03:48] application_test.go should eventually be gutted, split into unit tests and feature tests (using commands, preferably) [03:48] wallyworld: yeah I started it a while ago, but ran out of steam [03:49] there's a lot of existing tests [04:49] wallyworld: PTAL at https://github.com/juju/juju/pull/7100 [05:06] axw: looking [05:16] axw: the reworded messages look ok to me, ty [05:17] wallyworld: ta [07:46] wallyworld: here's the remove-machine branch: https://github.com/juju/juju/pull/7108 [07:51] ok === frankban|afk is now known as frankban [08:09] axw: lgtm, thanks [08:19] wallyworld: why do we need to update CI tests? [08:20] wallyworld: to check for those messages? as long as we don't expect them to be unchanging over time, I guess [08:20] (because it's meant for humans, not for scripts) [08:22] axw: that is true, but we want to be sure the correct units/storage etc are reported [08:23] okey dokey. probably should add it to the test plan for storage then [08:23] yeah [08:23] added a card [08:23] ta [08:23] axw: i asked because there were no feature tests as such, so nothing that did full end-end tests [08:24] of the new bits [08:24] wallyworld: might make more sense just to add one there, rather than running a separate CI test on all clouds [08:25] that would work [08:30] Bug #1466951 changed: juju incorrectly mixes http-proxy with apt-http-proxy and doesn't mix no-proxy

[08:42] Bug #1466951 opened: juju incorrectly mixes http-proxy with apt-http-proxy and doesn't mix no-proxy

[08:45] Bug #1466951 changed: juju incorrectly mixes http-proxy with apt-http-proxy and doesn't mix no-proxy

[08:51] the merge bots are a little bit crap today [09:03] axw: just a heads up: i'm just merging a PR that removes the state/workers package: https://github.com/juju/juju/pull/7074 [09:04] rogpeppe1: sounds good, thanks [09:04] axw: i like deleting code :) [09:04] me too, sadly I've been adding more than deleting lately :( [09:06] rogpeppe1: ah, I see you also fixed at least one of the 1.8 test failures.. just started looking at that. thanks. [09:06] axw: i fixed a couple of the 1.9 test failures too [09:06] heh, I haven't gone there yet [09:07] axw: i usually run on tip [09:07] rogpeppe1: do you see much instability along the way? [09:07] axw: the monotonic clocks muck up quite a few places that do DeepEquals on times [09:07] * axw nods [09:07] axw: no, not really [09:07] axw: it's generally rock solid all the time [09:08] cool [09:08] axw: using tip means that i can provide early feedback (e.g. a bug i reported resulted in the semantics of Time.Round and Time.Truncate changing) [09:09] rogpeppe1: yeah, I saw that. I should do the same, just a bit slack [09:09] axw: i think the go stability is a lesson in how it's possible to have a stable multiplatform product without gating commits directly on CI. [09:20] good morning! when i use juju to deploy a charm using containers (i.e. openstack) [09:21] i can see containers in maas, but, as i'm using an external dns they don't resolve, causing aodh for instance to fail. so question is: can juju (or better maas as it allocates hostname + ip) trigger a script/hook to invoke dns registration (and de-registration when lxd is released)? [09:21] this is a blocking issue for me === frankban is now known as frankban|afk === frankban|afk is now known as frankban === petevg_afk is now known as petevg === hml_ is now known as hml === hml_ is now known as hml === hml_ is now known as hml === hml_ is now known as hml === frankban is now known as frankban|afk [17:49] anyone around that can give this a review, please (a simple fix to a flaky test): https://github.com/juju/juju/pull/7113 === rogpeppe1 is now known as rogpeppe [18:19] the above PR now fixes three bugs in one, a bargain! review much appreciated: https://github.com/juju/juju/pull/7113 [18:20] perrito666: wanna take a look? [18:20] why not? :) [18:21] perrito666: thanks a lot :) [18:23] I wont make a fuzz about in your pr but... WTF " func (st *State) SetClockForTesting(clock clock.Clock) error " [18:24] rogpeppe: ship it, nice change, seems to add decent determinism [18:24] perrito666: thanks a lot; already saw your approval and hit $$merge$$ :) [18:24] perrito666: i think that much of the clock mocking fad in juju is misguided tbh [18:25] perrito666: clock mocking is useful when you know everything about the components you're testing, but not for higher levels [18:28] rogpeppe: I believe that live clock should never be used but perhaps our design should account for the fact that the clock can be replaced and behave accordingly to avoid out of band knowledge need [18:28] perrito666: i used to go along with that, but i have come to change my mind [18:29] perrito666: i think the live clock is the only decent way [18:29] perrito666: to avoid severely fragile test code [18:30] perrito666: otherwise you need to know exactly how many agents there are in the system and exactly what they are expected to do at any moment, so you know how many alarms to wait for [18:30] perrito666: and even then you have race conditions [18:30] perrito666: if Go provided support for clock mocking (a la Go playground) i think things might be different [18:32] perrito666: having a clock that runs faster than real-time is an another approach i've seen. that doesn't suffer the same problems. [18:33] rogpeppe: interesting, what changed your mind? [18:35] perrito666: trying to write robust tests using the clock mocking technique [18:36] perrito666: and finding them flaky even with appropriate values passed to WaitAdvance [18:36] rogpeppe: I do agree however that the ability to own the system clock would be a big win [18:36] perrito666: the problem is that the tests are also governed by the system clock [18:37] rogpeppe: true, true [18:37] perrito666: i like clock mocking when testing low level worker code where I know exactly what's going on [18:37] perrito666: and i still use it for that [18:37] I dont think I have a strong opinion in either aproach [18:38] perrito666: but pretending you can thread a mock clock through the whole system and have meaningful tests that won't break at the least change of unrelated code is... hopeful :) [18:38] perrito666, I'm just heading off, but if you're looking for something to do: https://github.com/juju/juju/pull/7110 [18:38] :) [18:38] perrito666: but i know it's kinda like a religion in juju-core these days :) [18:38] mattyw: I certainly am not but ill gladly review you [18:38] perrito666, haha, that's the spirit :) [18:39] perrito666: anyway, good to chat. i'm eod now, but hopefully catch you again before you go. [18:39] cheers, ill be her until the 21st :) [18:40] perrito666, less than a week? [18:40] mattyw: 3 work days [18:40] perrito666, counting down? [18:41] mattyw: it matches the day I have a vacation :) [20:06] rogpeppe: I'm not sure it helps much but I'm on your side of the testing clock debate - except for very narrow tests they hurt more than the problem they solve. [20:29] clock.Advance(1) [20:35] redir: yeah, I know you're a convert - we went through that pain together. [21:39] wallyworld, perrito666, thumper, hml, externalreality, menn0: anyone know about networking in GCE? I presume jam does, probably axw - anyone awake now? [21:39] NFI sorry [21:39] i don't know anything in detail [21:39] jam does [21:39] or at all i guess [22:06] babbageclunk: not i [22:27] babbageclunk: sorry, was on call and I don't know much about the topic [22:28] menn0: no worries, muddling along for now - will chat with jam later (although I guess he won't be around until Monday). [22:53] wallyworld: do you know who I should hit up to get my own GCE account? I'm beginning to get a bit nervous about messing around with the networks and firewall rules on the juju-qa account. [22:53] babbageclunk: i can find out [22:54] wallyworld: cool, thanks