[00:03] <thumper> davecheney: command doesn't depend on version.Version
[00:03] <thumper> I was thinking about adding some automatic deprecation checks
[00:03] <thumper> based on version
[00:04] <thumper> but I don't want to introduce the dependency
[00:04] <thumper> so I'll just go for 'deprecated bool'
[00:04] <thumper> oh...
[00:04] <thumper> you suggestion had me thinking...
[00:05]  * thumper will ponder for a bit
[00:14] <davecheney> thumper: wanna do the 1 on 1 now
[00:14] <thumper> davecheney: sure
[00:14] <davecheney> no reason to delay
[00:14] <davecheney> i'll see you in the hangout
[00:15] <thumper> kk
[02:07] <thumper> waigani: one to one?
[02:08] <waigani> thumper: ah, I'm in the wrong chan
[02:09] <waigani> thumper: my google cal is crashing for me - can you paste me the link please?
[03:14] <menn0> thumper, waigani: auto multi-env filtering: http://reviews.vapour.ws/r/551/diff/
[03:52] <thumper> menn0: awesome, looking now
[03:53] <thumper> menn0: hey, the diff fits on one page \o/
[03:55] <davecheney> +1
[03:56] <menn0> cool :)
[04:06] <waigani> thumper, menn0, davecheney: we have tests! http://reviews.vapour.ws/r/474/
[04:13] <davecheney> type ListMode bool
[04:13] <davecheney> var ( FullKeys     ListMode = true Fingerprints ListMode = false
[04:13] <davecheney> seriously
[04:13] <davecheney> this is an api parameter
[04:13] <davecheney> it has two states
[04:13] <davecheney> FullKeys or Fingerprints
[04:13] <davecheney> it is not possible to add a new state
[04:14] <davecheney> and when the gui calls it
[04:14] <davecheney> it has to say { Mode: true }
[04:14] <davecheney> What the F
[04:53] <waigani> menn0: http://reviews.vapour.ws/r/551/
[04:58] <waigani> menn0: just realised I didn't click 'publish'
[06:08] <axw> 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] <wallyworld_> axw: will do, thanks
[06:09] <wallyworld_> i'm going to ping andres later to set up a meeting for this week
[07:53] <davecheney> 2/win11
[08:19] <wallyworld_> axw: thanks for reviewing the gwacl mp, i just went to do it and it had been done \o/
[08:22] <axw> wallyworld_: no worries
[09:21] <wallyworld_> dimitern: thanks for looking at those networking bugs
[09:23] <dimitern> wallyworld_, np, I can do more if we had the lshw dump
[09:25] <wallyworld_> yeah, hopefully he can provide it
[10:03] <jam1> voidspace: standup ?
[10:03] <voidspace> oops
[10:03] <voidspace> jam1: omw
[10:05] <hazmat> 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] <hazmat> 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] <hazmat> fwiw
[10:47] <hazmat> jam, ping
[10:57] <hazmat> dimitern, out of curiosity what is the logic for juju-br0 selection?
[10:57]  * hazmat is looking at the lshw output
[10:58] <dimitern> hazmat, the first network device or the one with network:0 index in the lshw xml dump
[10:59] <hazmat> dimitern, aha.. default 0 behavior perhaps.. eth2 is mellanox with id="network"
[11:00] <dimitern> hazmat, can I see the dump?
[11:00] <hazmat> dimitern, its in the bug
[11:01] <hazmat> dimitern, https://bugs.launchpad.net/juju-core/+bug/1395908/+attachment/4267056/+files/1395908.tar.gz
[11:01] <mup> Bug #1395908: LXC containers in pending state due to juju-br0 misconfiguration <lxc> <oil> <juju-core:Triaged> <https://launchpad.net/bugs/1395908>
[11:02] <dimitern> hazmat, these are just logs, no lshw xml output
[11:05] <hazmat> hmm
[11:06] <hazmat> dimitern, right bug, wrong attachment.. https://bugs.launchpad.net/juju-core/+bug/1395908/+attachment/4271935/+files/lshw.tar.gz
[11:06] <mup> Bug #1395908: LXC containers in pending state due to juju-br0 misconfiguration <lxc> <oil> <juju-core:Triaged> <https://launchpad.net/bugs/1395908>
[11:09] <dimitern> hazmat, ah, I see the issue - the logic should skip network devices marked with disabled="true"
[11:39] <wallyworld_> hazmat: you free for the meeting about zone constraints later in your day?
[11:39] <hazmat> wallyworld_, yeah.. just rearrange the cal a bit for it
[11:39] <hazmat> er..i just rearranged
[11:39] <wallyworld_> hazmat: thanks, hard to find a time to suit aus, eng and us
[11:40] <hazmat> wallyworld_, np. thanks for setting it up.
[11:40] <wallyworld_> sure
[11:49] <voidspace> 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] <dimitern> voidspace, no need for Refresh
[11:52] <dimitern> 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] <voidspace> dimitern: yep, thanks
[11:52] <dimitern> voidspace, but those transitions can be handled internally with proper asserts
[11:54] <voidspace> 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] <dimitern> voidspace, yeah, so if that assert fails, we can reload the doc from state and retry
[11:54]  * fwereade_ lunch, walk
[11:55] <dimitern> voidspace, I'd suggest using SetStatus or SetState rather than UpdateState (for consistency with other state objects)
[11:55] <voidspace> dimitern: if we're just going to retry, why not just set the new state directly
[11:55] <voidspace> dimitern: (yes on name)
[11:55] <voidspace> dimitern: all we need to assert is that the ip address still exists
[11:56] <voidspace> dimitern: I would only check state if we're going to fail because of stale data
[11:57] <dimitern> voidspace, we need to retry in principle, because we assume stale data
[11:57] <voidspace> 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] <voidspace> dimitern: we don't care if it matches, we're setting the new state *anyway*
[11:58] <dimitern> 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] <voidspace> dimitern: can it only go forward?
[11:58] <voidspace> dimitern: I guess it should only go from "" to "allocated" or "unavailable"
[11:58] <voidspace> dimitern: but in which case we shouldn't retry, but fail
[11:59] <dimitern> voidspace, shouldn't we allow Unknown -> Allocated|Unavailable  only?
[11:59] <voidspace> dimitern: right - so we *shouldn't* retry then, we should fail
[11:59] <voidspace> and assert that State is Unknown
[11:59] <dimitern> voidspace, let's think how it'll go
[12:00] <voidspace> we pick a new address - initially created with State Unknown
[12:00] <voidspace> then we attempt to allocate and it goes to Allocated or Unavailable
[12:00] <dimitern> voidspace, new address -> set to unknown (i.e. "reserve" a doc for it until we decide the final state for that address)
[12:00] <voidspace> dimitern: until we start using this model for "other addresses"
[12:00] <dimitern> voidspace, existing unknown address -> set to allocated or unavailable, but fail if it's already set
[12:00] <voidspace> initially that's the only use case
[12:00] <dimitern> voidspace, *or* don't fail if the state is already the one we want to set
[12:01] <voidspace> ah, ok - so the assert is State == Unknown || NewState
[12:01] <dimitern> voidspace, yeah, I think so
[12:01] <voidspace> dimitern: do you know of an existing assert that is similar, so I can see how to implement that?
[12:02] <voidspace> I can just grep through state to see though
[12:02] <dimitern> voidspace, it's easy - you can combine assert
[12:02] <dimitern> voidspace, just a sec
[12:05] <dimitern> voidspace, unknownOrSame := bson.D{{"state", bson.D{{"$nin", []string{"unknown", newState}}}}}
[12:05] <voidspace> dimitern: thanks!
[12:05] <dimitern> $nin=not in list
[12:05] <dimitern> voidspace, np
[12:06] <voidspace> dimitern: so that asserts that the state *is* one of the listed ones?
[12:07] <dimitern> 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] <dimitern> (if it makes sense to)
[12:07] <voidspace> cool, thanks
[12:07] <voidspace> "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] <dimitern> voidspace, ah, sorry :)
[12:08] <dimitern> voidspace, you're right - it should've been "$in"
[12:08] <voidspace> dimitern: :-)
[12:10] <voidspace> dimitern: and SetState should be an IPAddress method rather than State.SetIPAddressState ?
[12:10] <voidspace> 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] <voidspace> (for no good reason it seems)
[12:10] <dimitern> voidspace, yes, that's the usual case
[12:11] <dimitern> voidspace, well - we create an "unknown" address, then update it to allocated or unavailable
[12:11] <voidspace> dimitern: yep
[13:25] <axw> 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] <axw> hazmat: as for the Azure API, doesn't look like it has much useful info in it
[13:26] <axw> I mean, useful to us...
[13:26]  * axw goes afk again
[13:27] <hazmat> axw, g'night
[13:42] <perrito666> brb
[14:01] <abentley> 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] <mattyw> has anyone seen fwereade_ ?
[14:59] <fwereade_> mattyw, I'm around, did I miss a ping?
[15:00] <mattyw> fwereade_, you might have done - but I'll forgive it
[15:05] <natefinch> perrito666: standup?
[15:06] <perrito666> ngetting there trying to find my headphones
[15:35] <voidspace> dimitern: should we require IP address type to be provided in the IPAddressInfo (argument to AddIPAddress)
[15:35] <voidspace> dimitern: or should we infer it from the actual address provided?
[15:36] <voidspace> dimitern: I'm inclined to infer it and remove it from IPAddressInfo
[15:36] <dimitern> voidspace, hmm.. why not take a network.Address instead?
[15:37] <voidspace> dimitern: ah, fair point
[15:37] <dimitern> voidspace, it has all the needed fields already, we just need to convert it from network.Address into a doc
[15:37] <voidspace> dimitern: ok, better do some reqorking
[15:37] <voidspace> dimitern: yep, good point
[15:37] <voidspace> dimitern: should I still validate the IP address?
[15:37] <voidspace> dimitern: I guess not
[15:38] <voidspace> dimitern: the only thing that prevents is *creating* an address in anything but an Unknown state
[15:38] <voidspace> dimitern: but if we ever have that use case it's easy to just call SetState after creation
[15:39] <dimitern> voidspace, I think we should validate it
[15:39] <voidspace> dimitern: ok
[15:39] <dimitern> voidspace, before storing it in state at least
[15:39] <voidspace> dimitern: yep
[15:39] <dimitern> voidspace, in the network package there are some validation methods I think you can use
[15:39] <voidspace> dimitern: net.ParseIP is easy enough
[15:40] <voidspace> I don't think I need anything more than that, but I can take a look
[15:41] <dimitern> voidspace, ok - I've just looked and there are no special validation methods for network.Address
[15:45] <voidspace> dimitern: I couldn't find any either... :-)
[15:46] <sinzui> natefinch, Can you get people to look into bug 1397376 and bug 1397995?
[15:46] <mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397376>
[15:46] <mup> Bug #1397995: 1.21b3: juju status isn't filtering by service <landscape> <regression> <status> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397995>
[15:47] <sinzui> 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] <mup> Bug #1396981: Upgrade fails with tools sha mismatch because product json is renamed <ci> <regression> <upgrade-juju> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1396981>
[15:53]  * perrito666 notices that google tells him that is going to upgrade his calendar ... nothing changes
[15:54] <natefinch> sinzui: ok
[15:56] <natefinch> 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] <fwereade_> natefinch, +1000
[15:57] <fwereade_> natefinch, it seriously sucks that I got distracted and never merged that
[15:57] <fwereade_> natefinch, getting it into the source tree would prevent it from being such a horrible hassle again
[15:58] <natefinch> fwereade_: that's what I was thinking.  I'll make a separate branch for it, shouldn't be too much work
[15:58] <fwereade_> natefinch, tyvm
[16:07] <alexisb> fwereade_, sorry, will be there shortly
[16:07] <fwereade_> alexisb, np
[16:14] <voidspace> dimitern: ooh, if we take a network.Address it doesn't allow us to set a MachineId, SubnetId or InterfaceId
[16:14] <voidspace> dimitern: shall I provide setters for those?
[16:14] <voidspace> dimitern: especially subnet id we want
[16:15] <dimitern> voidspace, hmm.. we can also take them as args
[16:15] <voidspace> dimitern: for SubnetId that makes sense
[16:15] <voidspace> dimitern: as we will always (initially) want it
[16:15] <voidspace> dimitern: MachineId and InterfaceId that will be a nuisance as we will rarely want to set them initially
[16:15] <dimitern> voidspace, yeah, and the rest (esp. machine id) won't be known at first
[16:15] <voidspace> dimitern: shall I add setter methods for those two?
[16:16] <dimitern> voidspace, let's have setters yeah
[16:16] <voidspace> dimitern: cool
[16:16] <dimitern> voidspace, cheers
[16:19] <voidspace> dimitern: hmmm... Dave Cheney said that we shouldn't add new dependencies to state
[16:19] <voidspace> dimitern: this PR adds network
[16:19] <voidspace> dimitern: I assume that "low-level" dependencies like that are permitted
[16:19] <dimitern> voidspace, good point
[16:19] <dimitern> voidspace, but I think we already import network in state
[16:20] <voidspace> dimitern: nope, it's showing in the diff
[16:20] <dimitern> voidspace, we do in some tests and in network.go
[16:21] <dimitern> voidspace, and in address.go
[16:21] <voidspace> ah...
[16:21] <voidspace> dimitern: right, so it's not actually a new dependency
[16:21] <voidspace> dimitern: I was just looking state/state.go
[16:21] <voidspace> :-)
[16:21] <dimitern> voidspace, :) whew..
[16:22] <dimitern> voidspace, well, for one this sort of dependency makes sense to me
[16:22] <voidspace> it's not a structural dependency which is the real problem
[16:22] <voidspace> and state has to deal with networking concepts
[16:22] <dimitern> exactly
[17:01] <alexisb> natefinch, IBM interlock
[17:34] <alexisb> jam, on and ready when you are
[18:48] <voidspace> g'night all
[18:49] <perrito666> gnight
[18:50] <voidspace> o/
[19:40] <sinzui> perrito666, natefinch , do either of you have time to review http://reviews.vapour.ws/r/554/diff/#
[19:42] <perrito666> sinzui: done, nate is most likely not here
[19:42] <sinzui> thank you perrito666
[19:42] <perrito666> yw
[19:47] <thumper> morning folks
[19:47] <perrito666> thumper: hi
[19:50] <thumper> sinzui: got a minute?
[19:51] <thumper> sinzui: I'd like to discuss https://bugs.launchpad.net/juju-core/+bug/1397376
[19:51] <mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397376>
[19:58] <sinzui> hi thumper, I do
[19:59] <thumper> sinzui: standup is about to start, can we talk after that?
[19:59] <sinzui> yep
[19:59] <thumper> cool
[20:14] <sinzui> 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] <thumper> sinzui: https://plus.google.com/hangouts/_/canonical.com/bug-1397376
[20:31] <bac> hey marcoceppi, we talked a while back about you releasing a new version of amulet.  can you schedule that for soonish?
[20:32] <davecheney> mwhudson: short version, there may be an announcement about the 1.5 cycle today
[20:32] <davecheney> but people are distracted with fixing 1.4 for release
[20:32] <mwhudson> davecheney: cool, thanks for chasing
[20:33] <davecheney> regarding spinning wheels on arm64 deveopment
[20:33] <davecheney> i understand
[20:33] <davecheney> i'm in the same boat
[20:38] <thumper> katco: you around?
[20:38] <katco> thumper: yup, what's up?
[20:38] <thumper> katco: seen https://bugs.launchpad.net/juju-core/+bug/1397995 ?
[20:38] <mup> Bug #1397995: 1.21b3: juju status isn't filtering by service <landscape> <regression> <status> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397995>
[20:38] <thumper> katco: thought of you because of your recent status changes
[20:38] <katco> thumper: yeah i saw that; likely it's related
[20:39] <katco> thumper: it looks like there was some kind of interplay between versions, but i just skimmed.
[20:39] <thumper> katco: can you look actively at it?
[20:39] <thumper> katco: it is blocking 1.21 release
[20:39] <katco> thumper: sure, just wrapping up latest set of review changes for leadership
[20:39] <thumper> kk
[20:39] <thumper> thanks
[20:39] <katco> thumper: thanks for pinging
[21:15] <wallyworld_> katco: hi, can we delay by 15 minutes? i'm in another meeting
[21:15] <katco> wallyworld_: sure thing
[21:15] <wallyworld_> ty
[21:42] <wallyworld_> katco: hi, i'm finally free
[21:43] <katco> wallyworld_: ok, hopping on
[21:55] <thumper> mwhudson: want to catch up now or soonish?
[21:55] <mwhudson> thumper: would about 20 mins work?
[21:55] <thumper> sure
[21:55] <mwhudson> cool
[22:30] <mwhudson> thumper: long 20 mins sorry, ready now
[22:30] <thumper> mwhudson: our 1:1 hangout?
[22:30] <mwhudson> thumper: sure, trying to find it now :)
[22:30] <mwhudson> ok, there
[23:59] <wallyworld_> 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] <mup> Bug #1389422: azure instance-types and regions missing <azure-provider> <constraints> <Go Windows Azure Client Library:Fix Committed by hazmat> <juju-core:In Progress by hazmat> <juju-core 1.20:Triaged> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1389422>