[00:00] and maas zones are part of that work/discussion [00:34] wallyworld: https://bugs.launchpad.net/juju-core/+bug/1382276 [00:34] Bug #1382276: Says environment is bootstrapped when it's not [01:12] katco: hi, can you pop onto the standup a minute early? [01:13] wallyworld: good timing :) [01:14] wallyworld: (i'm there already) [01:24] what is GOARCH on ppc64le? === uru_ is now known as urulama [05:29] bigjools: https://bugs.launchpad.net/juju-core/+bug/1382329 [05:29] Bug #1382329: juju 1.21-alpha1, unable to bootstrap to maas with --constraints arch=armhf / arm64 === uru_ is now known as urulama [08:04] morning all [08:07] morning all [08:30] morning [08:38] dimitern: I won't be around for standup *again* today I'm afraid [08:38] dimitern: dentist appointment [08:38] dimitern: I shouldn't be out too long [08:38] voidspace, no worries [08:38] dimitern: I organised it especially to avoid clashing with moonstone standups [08:38] dimitern: and then I changed team :-) [08:39] dimitern: I have a branch which I think is ready for review - it's trivial though (as discussed yesterday) [08:39] voidspace, :) well, I'll be standing up by myself then hehe [08:39] dimitern: ah yes [08:39] dimitern: no jam on Fridays and Frank is gardening [08:39] :-) [08:39] dimitern: enjoy [08:39] dimitern: don't talk for too long [08:47] morning voidspace [08:47] menn0: morning [08:47] menn0: or time-appropriate-greeting anyway... [08:48] voidspace: well I'm in your timezone so morning is just fine [08:48] voidspace: this is my last day working from the London office [08:48] menn0: you still in London? [08:48] menn0: ah [08:48] menn0: how's it been? [08:48] menn0: if you find Evan Dandrea, say hi to him for me [08:48] voidspace: good! [08:48] menn0: I guess a bunch of them are still in Brussels [08:48] Jesse has been here too so we've been working together but I'm on my own today [08:48] ah, cool [08:49] I'm seated amongst the phone team. it's been interesting seeing what they're up to. [08:50] have you been able to play with any hardware? [08:50] Tell them to test the "edge swipe" when the phone has a case on it (the type of case that has a lip round the screen) [08:50] well, maybe suggest it if you have the chance... [08:51] and they've probably thought of that anyway [08:51] voidspace: yeah the head of the phone team gave me a demo of the phone yesterday [08:52] voidspace: it's quite nice. amazing what they've managed to do in such a short time. [08:52] great [08:52] don't let them poach you! ;-) [10:25] tasdomas, ping [10:26] fwereade, pong [10:26] tasdomas, just came across the collectMetricsSignal thing, couple of thoughts [10:26] tasdomas, (1) shouldn't we continue to collect metrics while dying? [10:27] tasdomas, (2) shouldn't we set it up once, and trust it to keep firing, rather than recreating it every time through the loop [10:28] tasdomas, hmm, re (2), I guess we actually want to reset the timer once we trigger it, so we do need to create it repeatedly, so don't worry about that one [10:28] fwereade, recreation happens because we need the signal to fire as soon after the unit has started, and time.Ticker did not let me do that [10:29] fwereade, I don't think we need to collect metrics while the unit is dying [10:29] fwereade, I will discuss this with cmars, but I'm pretty sure that's the way we want it (at least for now) [10:30] tasdomas, ok, please do bring it up, a unit could potentially be dying but still delivering value for a long time [10:31] tasdomas, shame not to have the numbers available [10:31] fwereade, numbers? [10:31] tasdomas, the metrics we collect [10:31] tasdomas, it's just weird to have a potentially-long gap at the end of its lifetime [10:32] tasdomas, not the end of the world ofc [10:32] fwereade, well, it seems to me that a dying unit is a very unreliable thing to meter [10:34] tasdomas, yeah, maybe it's only useful if we also record when the unit started dying [12:46] fwereade: ping [12:47] menn0, pong [12:48] fwereade: I'm hitting road-block after road-block trying to get the machine env uuid upgrades to work [12:49] there are many things in the upgrade infrastructure itself that care about machines and instanceData [12:49] menn0, crap -- more things happening in the process of getting a state connection than we anticipated? [12:49] ahh, ok [12:49] the hack for getting the state connection is ok and worked [12:50] but then getting the upgrades to work is another story [12:50] the upgrades running functionality wants both a *state.State and an *api.State [12:50] I've implemented various hacks to get the API working well enough [12:51] but am now hitting problems with the upgrade sync stuff itself [12:51] hmm, I was wondering if we could make sure we ran the state-requiring upgrades first [12:51] that's what I'm thinking [12:51] treat these machine and related collection upgrades as a special case [12:51] minimising the window of yuckiness seems sane [12:52] and we can/do control the order of upgrades anyway, right? [12:52] we do [12:52] but currently we don't get to running any of them [12:52] and I understand why [12:52] but fixing it is getting super hacky [12:53] I'm thinking that about implementing something near the top of jujud's Run that gets a *state.State and runs selected upgrade steps manually [12:53] if it's the master machine agent [12:54] those steps would be removed from the list of steps for 1.21 [12:57] fwereade: does that sound reasonable to you? [12:59] in essence, yes, I think so [12:59] menn0, can we make the subsequent upgrade steps *not* take a *state.State then? [13:00] menn0, I'd be happiest if we could completely separate state changes from all the others, and always run the state ones first [13:01] fwereade: ok. upgrade steps for state servers only get *state.State now if running on a state server (obviously) [13:01] fwereade: what about upgrade steps that aren't DB migrations but might need to use state? [13:02] menn0, I'm hoping we don't have any, because philosophically speaking we shouldn't [13:02] menn0, I am prepared to be surprised/saddened though [13:02] fwereade: I'm looking at what we have now [13:02] fwereade: upgrade steps have been given a *State if running on a state server since before I started worked on this stuff [13:04] fwereade: well updateRsyslogPort is pretty special. it opens up its own private *State [13:04] * fwereade twitches gently [13:04] what's it doing that can't/shouldn't be done over the api? [13:04] fwereade: and then there's processDeprecatedEnvSettings which uses the provided *State [13:04] ditto [13:05] fwereade: it doesn't look like it. it needs to change something which is normally read-only [13:06] equally I'd be fine calling both those things data model changes [13:06] any reason not to run those in the first, needs-state batch? [13:06] and all the others in a second, needs-api batch? [13:08] fwereade: I think that sounds reasonable [13:08] fwereade: I'll have to think about how this effects the current upgrade sync functionality and the upgrade mechanics generally [13:10] menn0, cool, thanks [13:11] menn0, let me know what the next showstopper is ;p [13:11] fwereade: will do :) [13:12] fwereade: sigh. this might require some reorganisation of the upgrade-steps worker [13:12] man headbanging in closed spaces is dangerous [13:12] * perrito666 rubs forehead [13:13] morning all [13:17] morning perrito666 [13:17] sinzui: Have you had a chance to look at https://code.launchpad.net/~abentley/juju-ci-tools/industrial-test/+merge/238621 or my review of https://code.launchpad.net/~sinzui/juju-release-tools/validate-streams/+merge/237975 yet? [13:18] abentley, yes, sorry about the delays. You will see an email soon about the 1.20.10 problem [13:18] sinzui: Ah, gotcha. [13:29] fwereade: sigh. without machine and instanceData having been migrated, EnsureUpgradeInfo doesn't work. it's really feeling like these specific migrations are a special case that may need to be handled as such. [13:30] fwereade: I'm going to try that out and seeing how it looks. [13:31] menn0, ick [13:31] menn0, yeah, go for it [13:31] once I have it done I'll push it to my repo so you can have a look. I don't think it'll take long. [13:36] perrito666: 1:!? [13:36] going [14:47] fwereade: I was thinking something like this: https://github.com/mjs/juju/commit/b30135af56baa344efda84e54c4cc9c90b367d32 [14:47] fwereade: with this the upgrade from 1.20 works [14:48] menn0, it's a relief that that works [14:48] fwereade: I think this isn't quite right in terms of handling master changes during upgrades [14:48] fwereade: but I can fix that [14:48] menn0, can you estimate the cost of splitting upgrade steps up so we can separate state-needing ones from api-needing ones, and run them in that order using upgrade machinery? [14:49] menn0, if I wave my hands vigorously, it feels like it shouldn't be *fundamentally* hard, but I can believe it'd be a hassle [14:50] menn0, ie the upgrade machinery itself would need some work [14:50] fwereade: sure. I've already thought somewhat about this today. [14:51] fwereade: by "run them in that order using upgrade machinery" do you mean inside the upgrade-steps worker? (or at least managed by the UpgradeInfo system) [14:51] menn0, let's say the latter for now, given that I assume the former wants an api connection as well [14:52] fwereade: actually... quick hangout? I want to make sure we're on the same page. [14:53] menn0, sure [14:53] fwereade: https://plus.google.com/hangouts/_/gxxkhbn6ou7drvwcgmo3hd7wjea [14:53] fwereade: missed you [15:15] fwereade, quick question re. actions -- we want to land the whole CLI at once, at the very end, right? [15:16] bodie_, I think so, yeah -- but if you can come up with a smaller and self-consistent subset that's also fine [15:16] hmm, ok [15:17] fwereade, jcw4 and I have been thinking we should open CLI PRs against our juju-actions repo individually, and get them vetted, so we don't have a huge PR to pass all at once [15:17] bodie_, +100 to that [15:17] okay, cool [15:17] we can figure out what the subset is from there, maybe [15:18] thanks fwereade! === jcw4 is now known as jcw4|away [16:57] fwereade, are you done for the day? or do you have 5 minutes for an "in theory" discussion? === urulama_ is now known as urulama [17:33] happy weekend everyone === jcw4|away is now known as jcw4 [18:52] anyone know what happens when two sides disagree on scope:container? [19:03] a wormhole in space? [19:04] no I don't know [19:04] hazmat: interesting question to ask on a friday afternoon after a sprint [19:13] * perrito666 was 10 mins trying to figure out why his select was not working... he wrote switch instead [19:16] haha, I've done thart [19:21] sounds like something that could be a compiler error "too many type mismatches on your switch, you most likely are an airhead trying to use select" [19:21] heh perhaps [19:41] is there any doc for mup? there is no README on the repo.. or any other piece of non code information for the matter [19:58] mup: help [19:58] natefinch: Run "help " for details on: bug, echo, help, infer, poke, run, sendraw, sms [20:02] * perrito666 sighs and git clones [20:41] who the heck ever thought yaml was a GOOD idea :/. [20:43] what did that bad format do to you now? [20:45] your best bet is to actually write an editor for it [20:51] I'm trying to set min version in the charm metadata.yaml .... so like minversion: 1.20 .. but of course then yaml thinks that's a float, not a string, so I have to put it in quotes like minversion: "1.20" except then my code is saying \"1.20\" is not a valid version.... which seems to indicate it's getting the quotes as part of the string for some reason [20:52] mmm, I believe I saw gustavo and someone else discuss that particular issue not long ago [20:55] I think the actual reason is that our version parsing stuff always wants the micro version... so you have to say 1.20.0 [20:55] which is annoying [20:56] mmmm, true [20:56] which is not so bad itself cause that way you ommit alpha/beta version [20:57] anyway, gotta run [20:57] have a nice weekend everyone [20:58] u2