[00:03] davecheney: command doesn't depend on version.Version [00:03] I was thinking about adding some automatic deprecation checks [00:03] based on version [00:04] but I don't want to introduce the dependency [00:04] so I'll just go for 'deprecated bool' [00:04] oh... [00:04] you suggestion had me thinking... [00:05] * thumper will ponder for a bit === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [00:14] thumper: wanna do the 1 on 1 now [00:14] davecheney: sure [00:14] no reason to delay [00:14] i'll see you in the hangout [00:15] kk === kadams54 is now known as kadams54-away [02:07] waigani: one to one? [02:08] thumper: ah, I'm in the wrong chan [02:09] thumper: my google cal is crashing for me - can you paste me the link please? === kadams54 is now known as kadams54-away [03:14] thumper, waigani: auto multi-env filtering: http://reviews.vapour.ws/r/551/diff/ [03:52] menn0: awesome, looking now [03:53] menn0: hey, the diff fits on one page \o/ [03:55] +1 [03:56] cool :) [04:06] thumper, menn0, davecheney: we have tests! http://reviews.vapour.ws/r/474/ [04:13] type ListMode bool [04:13] var ( FullKeys ListMode = true Fingerprints ListMode = false [04:13] seriously [04:13] this is an api parameter [04:13] it has two states [04:13] FullKeys or Fingerprints [04:13] it is not possible to add a new state [04:14] and when the gui calls it [04:14] it has to say { Mode: true } [04:14] What the F === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [04:53] menn0: http://reviews.vapour.ws/r/551/ [04:58] menn0: just realised I didn't click 'publish' [06:08] wallyworld_: I'm working this afternoon, as I've got a school assembly to go to on Thursday morning and a school workshop on Friday morning. let me know if you need anything... [06:09] axw: will do, thanks [06:09] i'm going to ping andres later to set up a meeting for this week [07:53] 2/win11 [08:19] axw: thanks for reviewing the gwacl mp, i just went to do it and it had been done \o/ [08:22] wallyworld_: no worries [09:21] dimitern: thanks for looking at those networking bugs [09:23] wallyworld_, np, I can do more if we had the lshw dump [09:25] yeah, hopefully he can provide it [10:03] voidspace: standup ? [10:03] oops [10:03] jam1: omw [10:05] axw, the lshw /block dev question on the list brings up an interesting question.. if i do have say extra physical block devs on one unit but not others, would i see them? ie. storage spec is at a service level. thanks for the review and catch on azure regions [10:08] axw, hmm.. the microsoft guy pointed out a new api which does a limited form of the static map we're doing currently for azure http://msdn.microsoft.com/en-us/library/azure/gg441293.aspx [10:08] fwiw [10:47] jam, ping [10:57] dimitern, out of curiosity what is the logic for juju-br0 selection? [10:57] * hazmat is looking at the lshw output [10:58] hazmat, the first network device or the one with network:0 index in the lshw xml dump [10:59] dimitern, aha.. default 0 behavior perhaps.. eth2 is mellanox with id="network" [11:00] hazmat, can I see the dump? [11:00] dimitern, its in the bug [11:01] dimitern, https://bugs.launchpad.net/juju-core/+bug/1395908/+attachment/4267056/+files/1395908.tar.gz [11:01] Bug #1395908: LXC containers in pending state due to juju-br0 misconfiguration

[11:02] hazmat, these are just logs, no lshw xml output [11:05] hmm [11:06] dimitern, right bug, wrong attachment.. https://bugs.launchpad.net/juju-core/+bug/1395908/+attachment/4271935/+files/lshw.tar.gz [11:06] Bug #1395908: LXC containers in pending state due to juju-br0 misconfiguration

[11:09] hazmat, ah, I see the issue - the logic should skip network devices marked with disabled="true" [11:39] hazmat: you free for the meeting about zone constraints later in your day? [11:39] wallyworld_, yeah.. just rearrange the cal a bit for it [11:39] er..i just rearranged [11:39] hazmat: thanks, hard to find a time to suit aus, eng and us [11:40] wallyworld_, np. thanks for setting it up. [11:40] sure [11:49] dimitern: do you think IP address must have a Refresh method? We don't need it currently. (We did need it for Subnet.) [11:50] voidspace, no need for Refresh [11:52] voidspace, there won't be a life field; the only change that can happen is to set the state to "unavailable" or "allocated" [11:52] dimitern: yep, thanks [11:52] voidspace, but those transitions can be handled internally with proper asserts [11:54] dimitern: so UpdateState should take an IPAddress (rather than a string value) and assert that the state has not changed in the transaction that sets the new state? [11:54] voidspace, yeah, so if that assert fails, we can reload the doc from state and retry [11:54] * fwereade_ lunch, walk [11:55] voidspace, I'd suggest using SetStatus or SetState rather than UpdateState (for consistency with other state objects) [11:55] dimitern: if we're just going to retry, why not just set the new state directly [11:55] dimitern: (yes on name) [11:55] dimitern: all we need to assert is that the ip address still exists [11:56] dimitern: I would only check state if we're going to fail because of stale data [11:57] voidspace, we need to retry in principle, because we assume stale data [11:57] dimitern: if we're only setting a new state - and we will force that to succeed by retrying - why assert the old state matches? [11:57] dimitern: we don't care if it matches, we're setting the new state *anyway* [11:58] voidspace, if the address state goes only forward (like life) we need to ensure we won't set a state which is impossible [11:58] dimitern: can it only go forward? [11:58] dimitern: I guess it should only go from "" to "allocated" or "unavailable" [11:58] dimitern: but in which case we shouldn't retry, but fail [11:59] voidspace, shouldn't we allow Unknown -> Allocated|Unavailable only? [11:59] dimitern: right - so we *shouldn't* retry then, we should fail [11:59] and assert that State is Unknown [11:59] voidspace, let's think how it'll go [12:00] we pick a new address - initially created with State Unknown [12:00] then we attempt to allocate and it goes to Allocated or Unavailable [12:00] voidspace, new address -> set to unknown (i.e. "reserve" a doc for it until we decide the final state for that address) [12:00] dimitern: until we start using this model for "other addresses" [12:00] voidspace, existing unknown address -> set to allocated or unavailable, but fail if it's already set [12:00] initially that's the only use case [12:00] voidspace, *or* don't fail if the state is already the one we want to set [12:01] ah, ok - so the assert is State == Unknown || NewState [12:01] voidspace, yeah, I think so [12:01] dimitern: do you know of an existing assert that is similar, so I can see how to implement that? [12:02] I can just grep through state to see though [12:02] voidspace, it's easy - you can combine assert [12:02] voidspace, just a sec [12:05] voidspace, unknownOrSame := bson.D{{"state", bson.D{{"$nin", []string{"unknown", newState}}}}} [12:05] dimitern: thanks! [12:05] $nin=not in list [12:05] voidspace, np [12:06] dimitern: so that asserts that the state *is* one of the listed ones? [12:07] voidspace, yes -- we have a cached view of the data, and as long as this holds we're good, otherwise (assert fails) reload and redo [12:07] (if it makes sense to) [12:07] cool, thanks [12:07] "not in list" is an odd name for an assert that does the opposite (assert that the specified field *is* one of the ones in the list) [12:08] voidspace, ah, sorry :) [12:08] voidspace, you're right - it should've been "$in" [12:08] dimitern: :-) [12:10] dimitern: and SetState should be an IPAddress method rather than State.SetIPAddressState ? [12:10] we will always have an IPAddress when we need to use it, so it makes sense - I'd just assumed a State method though [12:10] (for no good reason it seems) [12:10] voidspace, yes, that's the usual case [12:11] voidspace, well - we create an "unknown" address, then update it to allocated or unavailable [12:11] dimitern: yep === kadams54 is now known as kadams54-away [13:25] hazmat: well, I had intended for storage specification to be at the unit level (specifiable at service level, which would cascade/merge down) [13:25] hazmat: as for the Azure API, doesn't look like it has much useful info in it [13:26] I mean, useful to us... [13:26] * axw goes afk again [13:27] axw, g'night [13:42] brb [14:01] sinzui: Industrial testing on AWS has been failing because there's no subnet for AZ us-east-1e: https://pastebin.canonical.com/121381/ [14:59] has anyone seen fwereade_ ? [14:59] mattyw, I'm around, did I miss a ping? [15:00] fwereade_, you might have done - but I'll forgive it [15:05] perrito666: standup? [15:06] ngetting there trying to find my headphones [15:35] dimitern: should we require IP address type to be provided in the IPAddressInfo (argument to AddIPAddress) [15:35] dimitern: or should we infer it from the actual address provided? [15:36] dimitern: I'm inclined to infer it and remove it from IPAddressInfo [15:36] voidspace, hmm.. why not take a network.Address instead? [15:37] dimitern: ah, fair point [15:37] voidspace, it has all the needed fields already, we just need to convert it from network.Address into a doc [15:37] dimitern: ok, better do some reqorking [15:37] dimitern: yep, good point [15:37] dimitern: should I still validate the IP address? [15:37] dimitern: I guess not [15:38] dimitern: the only thing that prevents is *creating* an address in anything but an Unknown state [15:38] dimitern: but if we ever have that use case it's easy to just call SetState after creation [15:39] voidspace, I think we should validate it [15:39] dimitern: ok [15:39] voidspace, before storing it in state at least [15:39] dimitern: yep [15:39] voidspace, in the network package there are some validation methods I think you can use [15:39] dimitern: net.ParseIP is easy enough [15:40] I don't think I need anything more than that, but I can take a look [15:41] voidspace, ok - I've just looked and there are no special validation methods for network.Address [15:45] dimitern: I couldn't find any either... :-) [15:46] natefinch, Can you get people to look into bug 1397376 and bug 1397995? [15:46] Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints

[15:46] Bug #1397995: 1.21b3: juju status isn't filtering by service

[15:47] natefinch, bug 1396981 is also critical, but needs discussion about scope. I am going to update the bug with my understanding of the issue [15:47] Bug #1396981: Upgrade fails with tools sha mismatch because product json is renamed

[15:53] * perrito666 notices that google tells him that is going to upgrade his calendar ... nothing changes [15:54] sinzui: ok [15:56] fwereade_: I was thinking, since I just used the skeleton provider to create the outline for the gce provider, maybe I should just copy it to make a real skeleton provider..... since I had to do a lot of work to get the skeleton provider to compile. [15:57] natefinch, +1000 [15:57] natefinch, it seriously sucks that I got distracted and never merged that [15:57] natefinch, getting it into the source tree would prevent it from being such a horrible hassle again [15:58] fwereade_: that's what I was thinking. I'll make a separate branch for it, shouldn't be too much work [15:58] natefinch, tyvm === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [16:07] fwereade_, sorry, will be there shortly [16:07] alexisb, np [16:14] dimitern: ooh, if we take a network.Address it doesn't allow us to set a MachineId, SubnetId or InterfaceId [16:14] dimitern: shall I provide setters for those? [16:14] dimitern: especially subnet id we want [16:15] voidspace, hmm.. we can also take them as args [16:15] dimitern: for SubnetId that makes sense [16:15] dimitern: as we will always (initially) want it [16:15] dimitern: MachineId and InterfaceId that will be a nuisance as we will rarely want to set them initially [16:15] voidspace, yeah, and the rest (esp. machine id) won't be known at first [16:15] dimitern: shall I add setter methods for those two? [16:16] voidspace, let's have setters yeah [16:16] dimitern: cool [16:16] voidspace, cheers [16:19] dimitern: hmmm... Dave Cheney said that we shouldn't add new dependencies to state [16:19] dimitern: this PR adds network [16:19] dimitern: I assume that "low-level" dependencies like that are permitted [16:19] voidspace, good point [16:19] voidspace, but I think we already import network in state [16:20] dimitern: nope, it's showing in the diff [16:20] voidspace, we do in some tests and in network.go [16:21] voidspace, and in address.go [16:21] ah... [16:21] dimitern: right, so it's not actually a new dependency [16:21] dimitern: I was just looking state/state.go [16:21] :-) [16:21] voidspace, :) whew.. [16:22] voidspace, well, for one this sort of dependency makes sense to me [16:22] it's not a structural dependency which is the real problem [16:22] and state has to deal with networking concepts [16:22] exactly === kadams54 is now known as kadams54-away [17:01] natefinch, IBM interlock === kadams54-away is now known as kadams54 [17:34] jam, on and ready when you are [18:48] g'night all [18:49] gnight [18:50] o/ === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [19:40] perrito666, natefinch , do either of you have time to review http://reviews.vapour.ws/r/554/diff/# [19:42] sinzui: done, nate is most likely not here [19:42] thank you perrito666 [19:42] yw [19:47] morning folks [19:47] thumper: hi [19:50] sinzui: got a minute? [19:51] sinzui: I'd like to discuss https://bugs.launchpad.net/juju-core/+bug/1397376 [19:51] Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints

[19:58] hi thumper, I do [19:59] sinzui: standup is about to start, can we talk after that? [19:59] yep [19:59] cool [20:14] hazmat, are you preparing the branch to inc the gwacl dep in juju-core master? Should I get the other developers on it. [20:20] sinzui: https://plus.google.com/hangouts/_/canonical.com/bug-1397376 [20:31] hey marcoceppi, we talked a while back about you releasing a new version of amulet. can you schedule that for soonish? [20:32] mwhudson: short version, there may be an announcement about the 1.5 cycle today [20:32] but people are distracted with fixing 1.4 for release [20:32] davecheney: cool, thanks for chasing [20:33] regarding spinning wheels on arm64 deveopment [20:33] i understand [20:33] i'm in the same boat === kadams54 is now known as kadams54-away [20:38] katco: you around? [20:38] thumper: yup, what's up? [20:38] katco: seen https://bugs.launchpad.net/juju-core/+bug/1397995 ? [20:38] Bug #1397995: 1.21b3: juju status isn't filtering by service

[20:38] katco: thought of you because of your recent status changes [20:38] thumper: yeah i saw that; likely it's related [20:39] thumper: it looks like there was some kind of interplay between versions, but i just skimmed. [20:39] katco: can you look actively at it? [20:39] katco: it is blocking 1.21 release [20:39] thumper: sure, just wrapping up latest set of review changes for leadership [20:39] kk [20:39] thanks [20:39] thumper: thanks for pinging === kadams54-away is now known as kadams54 [21:15] katco: hi, can we delay by 15 minutes? i'm in another meeting [21:15] wallyworld_: sure thing [21:15] ty === perrito6` is now known as perrito666 === psivaa_ is now known as psivaa === kadams54 is now known as kadams54-away [21:42] katco: hi, i'm finally free [21:43] wallyworld_: ok, hopping on === kadams54-away is now known as kadams54 [21:55] mwhudson: want to catch up now or soonish? [21:55] thumper: would about 20 mins work? [21:55] sure [21:55] cool === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [22:30] thumper: long 20 mins sorry, ready now [22:30] mwhudson: our 1:1 hangout? [22:30] thumper: sure, trying to find it now :) [22:30] ok, there === kadams54 is now known as kadams54-away [23:59] hazmat: you've got bug 1389422 as in progress on 1.22. i'm just updating 1.21 branch to pull in your new gwacl branch. i can do the same for 1.22 if you want [23:59] Bug #1389422: azure instance-types and regions missing