| 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:03 |
| 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:04 |
| * thumper will ponder for a bit | 00:05 | |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| 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:14 |
| thumper | kk | 00:15 |
| === kadams54 is now known as kadams54-away | ||
| thumper | waigani: one to one? | 02:07 |
| waigani | thumper: ah, I'm in the wrong chan | 02:08 |
| waigani | thumper: my google cal is crashing for me - can you paste me the link please? | 02:09 |
| === kadams54 is now known as kadams54-away | ||
| menn0 | thumper, waigani: auto multi-env filtering: http://reviews.vapour.ws/r/551/diff/ | 03:14 |
| thumper | menn0: awesome, looking now | 03:52 |
| thumper | menn0: hey, the diff fits on one page \o/ | 03:53 |
| davecheney | +1 | 03:55 |
| menn0 | cool :) | 03:56 |
| waigani | thumper, menn0, davecheney: we have tests! http://reviews.vapour.ws/r/474/ | 04:06 |
| 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:13 |
| davecheney | and when the gui calls it | 04:14 |
| davecheney | it has to say { Mode: true } | 04:14 |
| davecheney | What the F | 04:14 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| waigani | menn0: http://reviews.vapour.ws/r/551/ | 04:53 |
| waigani | menn0: just realised I didn't click 'publish' | 04:58 |
| 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:08 |
| wallyworld_ | axw: will do, thanks | 06:09 |
| wallyworld_ | i'm going to ping andres later to set up a meeting for this week | 06:09 |
| davecheney | 2/win11 | 07:53 |
| wallyworld_ | axw: thanks for reviewing the gwacl mp, i just went to do it and it had been done \o/ | 08:19 |
| axw | wallyworld_: no worries | 08:22 |
| wallyworld_ | dimitern: thanks for looking at those networking bugs | 09:21 |
| dimitern | wallyworld_, np, I can do more if we had the lshw dump | 09:23 |
| wallyworld_ | yeah, hopefully he can provide it | 09:25 |
| jam1 | voidspace: standup ? | 10:03 |
| voidspace | oops | 10:03 |
| voidspace | jam1: omw | 10:03 |
| 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:05 |
| 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:08 |
| hazmat | jam, ping | 10:47 |
| hazmat | dimitern, out of curiosity what is the logic for juju-br0 selection? | 10:57 |
| * hazmat is looking at the lshw output | 10:57 | |
| dimitern | hazmat, the first network device or the one with network:0 index in the lshw xml dump | 10:58 |
| hazmat | dimitern, aha.. default 0 behavior perhaps.. eth2 is mellanox with id="network" | 10:59 |
| dimitern | hazmat, can I see the dump? | 11:00 |
| hazmat | dimitern, its in the bug | 11:00 |
| 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:01 |
| dimitern | hazmat, these are just logs, no lshw xml output | 11:02 |
| hazmat | hmm | 11:05 |
| 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:06 |
| dimitern | hazmat, ah, I see the issue - the logic should skip network devices marked with disabled="true" | 11:09 |
| 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:39 |
| hazmat | wallyworld_, np. thanks for setting it up. | 11:40 |
| wallyworld_ | sure | 11:40 |
| 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:49 |
| dimitern | voidspace, no need for Refresh | 11:50 |
| 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:52 |
| 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:54 | |
| 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:55 |
| voidspace | dimitern: I would only check state if we're going to fail because of stale data | 11:56 |
| 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:57 |
| 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:58 |
| 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 | 11:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:05 |
| voidspace | dimitern: so that asserts that the state *is* one of the listed ones? | 12:06 |
| 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:07 |
| dimitern | voidspace, ah, sorry :) | 12:08 |
| dimitern | voidspace, you're right - it should've been "$in" | 12:08 |
| voidspace | dimitern: :-) | 12:08 |
| 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:10 |
| dimitern | voidspace, well - we create an "unknown" address, then update it to allocated or unavailable | 12:11 |
| voidspace | dimitern: yep | 12:11 |
| === kadams54 is now known as kadams54-away | ||
| 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:25 |
| axw | I mean, useful to us... | 13:26 |
| * axw goes afk again | 13:26 | |
| hazmat | axw, g'night | 13:27 |
| perrito666 | brb | 13:42 |
| 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:01 |
| mattyw | has anyone seen fwereade_ ? | 14:59 |
| fwereade_ | mattyw, I'm around, did I miss a ping? | 14:59 |
| mattyw | fwereade_, you might have done - but I'll forgive it | 15:00 |
| natefinch | perrito666: standup? | 15:05 |
| perrito666 | ngetting there trying to find my headphones | 15:06 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| voidspace | I don't think I need anything more than that, but I can take a look | 15:40 |
| dimitern | voidspace, ok - I've just looked and there are no special validation methods for network.Address | 15:41 |
| voidspace | dimitern: I couldn't find any either... :-) | 15:45 |
| 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:46 |
| 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:47 |
| * perrito666 notices that google tells him that is going to upgrade his calendar ... nothing changes | 15:53 | |
| natefinch | sinzui: ok | 15:54 |
| 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:56 |
| 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:57 |
| 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 | 15:58 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| alexisb | fwereade_, sorry, will be there shortly | 16:07 |
| fwereade_ | alexisb, np | 16:07 |
| 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:14 |
| 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:15 |
| dimitern | voidspace, let's have setters yeah | 16:16 |
| voidspace | dimitern: cool | 16:16 |
| dimitern | voidspace, cheers | 16:16 |
| 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:19 |
| voidspace | dimitern: nope, it's showing in the diff | 16:20 |
| dimitern | voidspace, we do in some tests and in network.go | 16:20 |
| 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:21 |
| 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 | 16:22 |
| === kadams54 is now known as kadams54-away | ||
| alexisb | natefinch, IBM interlock | 17:01 |
| === kadams54-away is now known as kadams54 | ||
| alexisb | jam, on and ready when you are | 17:34 |
| voidspace | g'night all | 18:48 |
| perrito666 | gnight | 18:49 |
| voidspace | o/ | 18:50 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| sinzui | perrito666, natefinch , do either of you have time to review http://reviews.vapour.ws/r/554/diff/# | 19:40 |
| perrito666 | sinzui: done, nate is most likely not here | 19:42 |
| sinzui | thank you perrito666 | 19:42 |
| perrito666 | yw | 19:42 |
| thumper | morning folks | 19:47 |
| perrito666 | thumper: hi | 19:47 |
| thumper | sinzui: got a minute? | 19:50 |
| 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:51 |
| sinzui | hi thumper, I do | 19:58 |
| thumper | sinzui: standup is about to start, can we talk after that? | 19:59 |
| sinzui | yep | 19:59 |
| thumper | cool | 19:59 |
| 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:14 |
| thumper | sinzui: https://plus.google.com/hangouts/_/canonical.com/bug-1397376 | 20:20 |
| bac | hey marcoceppi, we talked a while back about you releasing a new version of amulet. can you schedule that for soonish? | 20:31 |
| 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:32 |
| davecheney | regarding spinning wheels on arm64 deveopment | 20:33 |
| davecheney | i understand | 20:33 |
| davecheney | i'm in the same boat | 20:33 |
| === kadams54 is now known as kadams54-away | ||
| 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:38 |
| 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 | 20:39 |
| === kadams54-away is now known as kadams54 | ||
| 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:15 |
| === perrito6` is now known as perrito666 | ||
| === psivaa_ is now known as psivaa | ||
| === kadams54 is now known as kadams54-away | ||
| wallyworld_ | katco: hi, i'm finally free | 21:42 |
| katco | wallyworld_: ok, hopping on | 21:43 |
| === kadams54-away is now known as kadams54 | ||
| 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 | 21:55 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| 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 | 22:30 |
| === kadams54 is now known as kadams54-away | ||
| 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> | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!