[00:00] <rick_h_> and maas zones are part of that work/discussion
[00:34] <bigjools> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1382276
[00:34] <mup> Bug #1382276: Says environment is bootstrapped when it's not <juju-core:New> <https://launchpad.net/bugs/1382276>
[01:12] <wallyworld> katco: hi, can you pop onto the standup a minute early?
[01:13] <katco> wallyworld: good timing :)
[01:14] <katco> wallyworld: (i'm there already)
[01:24] <mwhudson> what is GOARCH on ppc64le?
[05:29] <wallyworld_> bigjools: https://bugs.launchpad.net/juju-core/+bug/1382329
[05:29] <mup> Bug #1382329: juju 1.21-alpha1, unable to bootstrap to maas with --constraints arch=armhf / arm64  <hs-arm64> <juju-core:New> <https://launchpad.net/bugs/1382329>
[08:04] <mattyw> morning all
[08:07] <voidspace> morning all
[08:30] <dimitern> morning
[08:38] <voidspace> dimitern: I won't be around for standup *again* today I'm afraid
[08:38] <voidspace> dimitern: dentist appointment
[08:38] <voidspace> dimitern: I shouldn't be out too long
[08:38] <dimitern> voidspace, no worries
[08:38] <voidspace> dimitern: I organised it especially to avoid clashing with moonstone standups
[08:38] <voidspace> dimitern: and then I changed team :-)
[08:39] <voidspace> dimitern: I have a branch which I think is ready for review - it's trivial though (as discussed yesterday)
[08:39] <dimitern> voidspace, :) well, I'll be standing up by myself then hehe
[08:39] <voidspace> dimitern: ah yes
[08:39] <voidspace> dimitern: no jam on Fridays and Frank is gardening
[08:39] <voidspace> :-)
[08:39] <voidspace> dimitern: enjoy
[08:39] <voidspace> dimitern: don't talk for too long
[08:47] <menn0> morning voidspace
[08:47] <voidspace> menn0: morning
[08:47] <voidspace> menn0: or time-appropriate-greeting anyway...
[08:48] <menn0> voidspace: well I'm in your timezone so morning is just fine
[08:48] <menn0> voidspace: this is my last day working from the London office
[08:48] <voidspace> menn0: you still in London?
[08:48] <voidspace> menn0: ah
[08:48] <voidspace> menn0: how's it been?
[08:48] <voidspace> menn0: if you find Evan Dandrea, say hi to him for me
[08:48] <menn0> voidspace: good!
[08:48] <voidspace> menn0: I guess a bunch of them are still in Brussels
[08:48] <menn0> Jesse has been here too so we've been working together but I'm on my own today
[08:48] <voidspace> ah, cool
[08:49] <menn0> I'm seated amongst the phone team. it's been interesting seeing what they're up to.
[08:50] <voidspace> have you been able to play with any hardware?
[08:50] <voidspace> 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] <voidspace> well, maybe suggest it if you have the chance...
[08:51] <voidspace> and they've probably thought of that anyway
[08:51] <menn0> voidspace: yeah the head of the phone team gave me a demo of the phone yesterday
[08:52] <menn0> voidspace: it's quite nice. amazing what they've managed to do in such a short time.
[08:52] <voidspace> great
[08:52] <voidspace> don't let them poach you! ;-)
[10:25] <fwereade> tasdomas, ping
[10:26] <tasdomas> fwereade, pong
[10:26] <fwereade> tasdomas, just came across the collectMetricsSignal thing, couple of thoughts
[10:26] <fwereade> tasdomas, (1) shouldn't we continue to collect metrics while dying?
[10:27] <fwereade> 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] <fwereade> 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] <tasdomas> 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] <tasdomas> fwereade, I don't think we need to collect metrics while the unit is dying
[10:29] <tasdomas> 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] <fwereade> tasdomas, ok, please do bring it up, a unit could potentially be dying but still delivering value for a long time
[10:31] <fwereade> tasdomas, shame not to have the numbers available
[10:31] <tasdomas> fwereade, numbers?
[10:31] <fwereade> tasdomas, the metrics we collect
[10:31] <fwereade> tasdomas, it's just weird to have a potentially-long gap at the end of its lifetime
[10:32] <fwereade> tasdomas, not the end of the world ofc
[10:32] <tasdomas> fwereade, well, it seems to me that a dying unit is a very unreliable thing to meter
[10:34] <fwereade> tasdomas, yeah, maybe it's only useful if we also record when the unit started dying
[12:46] <menn0> fwereade: ping
[12:47] <fwereade> menn0, pong
[12:48] <menn0> fwereade: I'm hitting road-block after road-block trying to get the machine env uuid upgrades to work
[12:49] <menn0> there are many things in the upgrade infrastructure itself that care about machines and instanceData
[12:49] <fwereade> menn0, crap -- more things happening in the process of getting a state connection than we anticipated?
[12:49] <fwereade> ahh, ok
[12:49] <menn0> the hack for getting the state connection is ok and worked
[12:50] <menn0> but then getting the upgrades to work is another story
[12:50] <menn0> the upgrades running functionality wants both a *state.State and an *api.State
[12:50] <menn0> I've implemented various hacks to get the API working well enough
[12:51] <menn0> but am now hitting problems with the upgrade sync stuff itself
[12:51] <fwereade> hmm, I was wondering if we could make sure we ran the state-requiring upgrades first
[12:51] <menn0> that's what I'm thinking
[12:51] <menn0> treat these machine and related collection upgrades as a special case
[12:51] <fwereade> minimising the window of yuckiness seems sane
[12:52] <fwereade> and we can/do control the order of upgrades anyway, right?
[12:52] <menn0> we do
[12:52] <menn0> but currently we don't get to running any of them
[12:52] <menn0> and I understand why
[12:52] <menn0> but fixing it is getting super hacky
[12:53] <menn0> 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] <menn0> if it's the master machine agent
[12:54] <menn0> those steps would be removed from the list of steps for 1.21
[12:57] <menn0> fwereade: does that sound reasonable to you?
[12:59] <fwereade> in essence, yes, I think so
[12:59] <fwereade> menn0, can we make the subsequent upgrade steps *not* take a *state.State then?
[13:00] <fwereade> 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] <menn0> fwereade: ok. upgrade steps for state servers only get *state.State now if running on a state server (obviously)
[13:01] <menn0> fwereade: what about upgrade steps that aren't DB migrations but might need to use state?
[13:02] <fwereade> menn0, I'm hoping we don't have any, because philosophically speaking we shouldn't
[13:02] <fwereade> menn0, I am prepared to be surprised/saddened though
[13:02] <menn0> fwereade: I'm looking at what we have now
[13:02] <menn0> fwereade: upgrade steps have been given a *State if running on a state server since before I started worked on this stuff
[13:04] <menn0> fwereade: well updateRsyslogPort is pretty special. it opens up its own private *State
[13:04]  * fwereade twitches gently
[13:04] <fwereade> what's it doing that can't/shouldn't be done over the api?
[13:04] <menn0> fwereade: and then there's processDeprecatedEnvSettings which uses the provided *State
[13:04] <fwereade> ditto
[13:05] <menn0> fwereade: it doesn't look like it. it needs to change something which is normally read-only
[13:06] <fwereade> equally I'd be fine calling both those things data model changes
[13:06] <fwereade> any reason not to run those in the first, needs-state batch?
[13:06] <fwereade> and all the others in a second, needs-api batch?
[13:08] <menn0> fwereade: I think that sounds reasonable
[13:08] <menn0> fwereade: I'll have to think about how this effects the current upgrade sync functionality and the upgrade mechanics generally
[13:10] <fwereade> menn0, cool, thanks
[13:11] <fwereade> menn0, let me know what the next showstopper is ;p
[13:11] <menn0> fwereade: will do :)
[13:12] <menn0> fwereade: sigh. this might require some reorganisation of the upgrade-steps worker
[13:12] <perrito666> man headbanging in closed spaces is dangerous
[13:12]  * perrito666 rubs forehead
[13:13] <perrito666> morning all
[13:17] <jcw4> morning perrito666
[13:17] <abentley> 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] <sinzui> abentley, yes, sorry about the delays. You will see an email soon about the 1.20.10 problem
[13:18] <abentley> sinzui: Ah, gotcha.
[13:29] <menn0> 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] <menn0> fwereade: I'm going to try that out and seeing how it looks.
[13:31] <fwereade> menn0, ick
[13:31] <fwereade> menn0, yeah, go for it
[13:31] <menn0> 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] <natefinch> perrito666: 1:!?
[13:36] <perrito666> going
[14:47] <menn0> fwereade: I was thinking something like this: https://github.com/mjs/juju/commit/b30135af56baa344efda84e54c4cc9c90b367d32
[14:47] <menn0> fwereade: with this the upgrade from 1.20 works
[14:48] <fwereade> menn0, it's a relief that that works
[14:48] <menn0> fwereade: I think this isn't quite right in terms of handling master changes during upgrades
[14:48] <menn0> fwereade: but I can fix that
[14:48] <fwereade> 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] <fwereade> 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] <fwereade> menn0, ie the upgrade machinery itself would need some work
[14:50] <menn0> fwereade: sure. I've already thought somewhat about this today.
[14:51] <menn0> 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] <fwereade> menn0, let's say the latter for now, given that I assume the former wants an api connection as well
[14:52] <menn0> fwereade: actually... quick hangout? I want to make sure we're on the same page.
[14:53] <fwereade> menn0, sure
[14:53] <menn0> fwereade: https://plus.google.com/hangouts/_/gxxkhbn6ou7drvwcgmo3hd7wjea
[14:53] <menn0> fwereade: missed you
[15:15] <bodie_> fwereade, quick question re. actions -- we want to land the whole CLI at once, at the very end, right?
[15:16] <fwereade> bodie_, I think so, yeah -- but if you can come up with a smaller and self-consistent subset that's also fine
[15:16] <bodie_> hmm, ok
[15:17] <bodie_> 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] <fwereade> bodie_, +100 to that
[15:17] <bodie_> okay, cool
[15:17] <bodie_> we can figure out what the subset is from there, maybe
[15:18] <bodie_> thanks fwereade!
[16:57] <mattyw> fwereade, are you done for the day? or do you have 5 minutes for an "in theory" discussion?
[17:33] <voidspace> happy weekend everyone
[18:52] <hazmat> anyone know what happens when two sides disagree on scope:container?
[19:03] <natefinch> a wormhole in space?
[19:04] <natefinch> no I don't know
[19:04] <perrito666> 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] <natefinch> haha, I've done thart
[19:21] <perrito666> 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] <natefinch> heh perhaps
[19:41] <perrito666> 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] <natefinch> mup: help
[19:58] <mup> natefinch: Run "help <cmdname>" for details on: bug, echo, help, infer, poke, run, sendraw, sms
[20:02]  * perrito666 sighs and git clones
[20:41] <natefinch> who the heck ever thought yaml was a GOOD idea :/.
[20:43] <perrito666> what did that bad format do to you now?
[20:45] <perrito666> your best bet is to actually write an editor for it
[20:51] <natefinch> 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] <perrito666> mmm, I believe I saw gustavo and someone else discuss that particular issue not long ago
[20:55] <natefinch> 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] <natefinch> which is annoying
[20:56] <perrito666> mmmm, true
[20:56] <perrito666> which is not so bad itself cause that way you ommit alpha/beta version
[20:57] <natefinch> anyway, gotta run
[20:57] <natefinch> have a nice weekend everyone
[20:58] <perrito666> u2