| rick_h_ | and maas zones are part of that work/discussion | 00:00 |
|---|---|---|
| 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> | 00:34 |
| wallyworld | katco: hi, can you pop onto the standup a minute early? | 01:12 |
| katco | wallyworld: good timing :) | 01:13 |
| katco | wallyworld: (i'm there already) | 01:14 |
| mwhudson | what is GOARCH on ppc64le? | 01:24 |
| === uru_ is now known as urulama | ||
| 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> | 05:29 |
| === uru_ is now known as urulama | ||
| mattyw | morning all | 08:04 |
| voidspace | morning all | 08:07 |
| dimitern | morning | 08:30 |
| 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:38 |
| 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:39 |
| menn0 | morning voidspace | 08:47 |
| voidspace | menn0: morning | 08:47 |
| voidspace | menn0: or time-appropriate-greeting anyway... | 08:47 |
| 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:48 |
| menn0 | I'm seated amongst the phone team. it's been interesting seeing what they're up to. | 08:49 |
| 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:50 |
| 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:51 |
| 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! ;-) | 08:52 |
| fwereade | tasdomas, ping | 10:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| fwereade | tasdomas, ok, please do bring it up, a unit could potentially be dying but still delivering value for a long time | 10:30 |
| 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:31 |
| 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:32 |
| fwereade | tasdomas, yeah, maybe it's only useful if we also record when the unit started dying | 10:34 |
| menn0 | fwereade: ping | 12:46 |
| fwereade | menn0, pong | 12:47 |
| menn0 | fwereade: I'm hitting road-block after road-block trying to get the machine env uuid upgrades to work | 12:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| menn0 | those steps would be removed from the list of steps for 1.21 | 12:54 |
| menn0 | fwereade: does that sound reasonable to you? | 12:57 |
| fwereade | in essence, yes, I think so | 12:59 |
| fwereade | menn0, can we make the subsequent upgrade steps *not* take a *state.State then? | 12:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| menn0 | fwereade: it doesn't look like it. it needs to change something which is normally read-only | 13:05 |
| 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:06 |
| 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:08 |
| fwereade | menn0, cool, thanks | 13:10 |
| fwereade | menn0, let me know what the next showstopper is ;p | 13:11 |
| menn0 | fwereade: will do :) | 13:11 |
| 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:12 | |
| perrito666 | morning all | 13:13 |
| 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:17 |
| 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:18 |
| 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:29 |
| menn0 | fwereade: I'm going to try that out and seeing how it looks. | 13:30 |
| 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:31 |
| natefinch | perrito666: 1:!? | 13:36 |
| perrito666 | going | 13:36 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| menn0 | fwereade: actually... quick hangout? I want to make sure we're on the same page. | 14:52 |
| fwereade | menn0, sure | 14:53 |
| menn0 | fwereade: https://plus.google.com/hangouts/_/gxxkhbn6ou7drvwcgmo3hd7wjea | 14:53 |
| menn0 | fwereade: missed you | 14:53 |
| bodie_ | fwereade, quick question re. actions -- we want to land the whole CLI at once, at the very end, right? | 15:15 |
| 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:16 |
| 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:17 |
| bodie_ | thanks fwereade! | 15:18 |
| === jcw4 is now known as jcw4|away | ||
| mattyw | fwereade, are you done for the day? or do you have 5 minutes for an "in theory" discussion? | 16:57 |
| === urulama_ is now known as urulama | ||
| voidspace | happy weekend everyone | 17:33 |
| === jcw4|away is now known as jcw4 | ||
| hazmat | anyone know what happens when two sides disagree on scope:container? | 18:52 |
| natefinch | a wormhole in space? | 19:03 |
| natefinch | no I don't know | 19:04 |
| perrito666 | hazmat: interesting question to ask on a friday afternoon after a sprint | 19:04 |
| * perrito666 was 10 mins trying to figure out why his select was not working... he wrote switch instead | 19:13 | |
| natefinch | haha, I've done thart | 19:16 |
| 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:21 |
| 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:41 |
| natefinch | mup: help | 19:58 |
| mup | natefinch: Run "help <cmdname>" for details on: bug, echo, help, infer, poke, run, sendraw, sms | 19:58 |
| * perrito666 sighs and git clones | 20:02 | |
| natefinch | who the heck ever thought yaml was a GOOD idea :/. | 20:41 |
| perrito666 | what did that bad format do to you now? | 20:43 |
| perrito666 | your best bet is to actually write an editor for it | 20:45 |
| 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:51 |
| perrito666 | mmm, I believe I saw gustavo and someone else discuss that particular issue not long ago | 20:52 |
| 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:55 |
| perrito666 | mmmm, true | 20:56 |
| perrito666 | which is not so bad itself cause that way you ommit alpha/beta version | 20:56 |
| natefinch | anyway, gotta run | 20:57 |
| natefinch | have a nice weekend everyone | 20:57 |
| perrito666 | u2 | 20:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!