| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-06 | |||
| 15:48:55 | stephenfin | mriedem: Sure https://etherpad.openstack.org/p/nova-train-prelude | |
| 15:51:25 | efried | thanks | |
| 15:51:39 | efried | is a prelude related to cycle highlights? | |
| 15:51:44 | mriedem | sort of, | |
| 15:51:46 | efried | cause I could use a delegate for that as well | |
| 15:51:53 | mriedem | the prelude generally feeds into highlights | |
| 15:52:10 | mriedem | the highlights have to be wordsmithed a bit for marketing speak | |
| 15:52:17 | efried | it's cruel that first draft of highlights is due the day of FF. | |
| 15:52:35 | mriedem | "the compute team leveraged the synergy of the cloud to...deprecate the xenapi driver" | |
| 15:52:45 | mriedem | efried: yup | |
| 15:52:50 | mriedem | i've complained about that before | |
| 15:53:08 | mriedem | smcginnis is good at suggestions on the highlights, | |
| 15:53:13 | mriedem | he's nearly executive level management at this point | |
| 15:53:19 | stephenfin | efried: I'm hoping to put together one of those internally to figure out what we need to test/document for Train/OSP16. I'll share it but it won't be 'til Wednesday week, which is probably too late? | |
| 15:53:19 | mriedem | he only speaks that langauge | |
| 15:53:38 | mriedem | stephenfin: FF is thursday | |
| 15:53:46 | efried | stephenfin: unless you accept that this task has been delegated to you. | |
| 15:54:02 | efried | then Thursday is the "deadline" for the "first draft", so Wednesday is a whole day early! | |
| 15:54:19 | efried | iow, it's all yours, and I don't need to vet/edit/revise it. | |
| 15:55:15 | smcginnis | efried: I'm not happy about the deadline either, but the OSF marketing folks said they needed that info earlier. :/ | |
| 15:55:47 | mriedem | need to copy/paste into a chart asap | |
| 15:55:50 | stephenfin | efried, mriedem: okay, I'll do it Monday | |
| 15:56:17 | mriedem | maybe we should put an easter egg in the highlights... | |
| 15:56:21 | mriedem | see who's paying attention | |
| 15:56:22 | efried | I'm not blaming anyone, and I'm sure there's a "good" reason. It's just like, we're already all one-armed paper hangers already. | |
| 15:56:29 | efried | mriedem: love that idea. | |
| 15:56:45 | mriedem | "nova is deprecated, all hail serverless" | |
| 16:00:16 | stephenfin | There's one non-doc patch left in the remove-consoleauth series that I thought had already merged. If anyone has bandwidth to push it through (melwitt is +2), that'd be dandy https://review.opendev.org/#/c/652970/ | |
| 16:00:29 | stephenfin | I'm just going to abandon the other two | |
| 16:02:57 | dustinc | mriedem, efried, dtantsur|afk: all caught up, thanks for your help | |
| 16:04:29 | efried | stephenfin: left a question there | |
| 16:04:41 | efried | it looks like a behavior change to me | |
| 16:05:14 | mriedem | efried: +2 on that deps update for the sighup fix https://review.opendev.org/#/c/679974/ - mnaser / dansmith fyi on that | |
| 16:05:21 | efried | thanks mriedem | |
| 16:05:23 | mriedem | definitely rc blocker | |
| 16:06:28 | dansmith | efried: I was thinking you had tested something related to sighup and decided that it was *not* properly restarting us after the fix | |
| 16:06:35 | dansmith | efried: did I misunderstand that or did something else change? | |
| 16:07:00 | efried | dansmith: that was at the point where we only had the oslo.service fix. I dug further and fixed the oslo.privsep issue. With both fixes together, shit works. | |
| 16:07:11 | dansmith | gotcha okay cool | |
| 16:07:13 | efried | links from that patch --^ | |
| 16:07:54 | dansmith | efried: yeah okay I didn't get that from the reno when I first read it, | |
| 16:08:03 | dansmith | but I didn't study both bugs and just wanted to make sure | |
| 16:08:10 | efried | ++ | |
| 16:08:16 | melwitt | efried, stephenfinI think you're right :/ I didn't notice that. commenting | |
| 16:08:37 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] testing with new lable. https://review.opendev.org/680738 | |
| 16:08:37 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] testing with old lable https://review.opendev.org/680739 | |
| 16:08:44 | efried | melwitt: looking again, I think the one I commented on is okay, but the one a couple lines down should be access_url, not access_url_base. | |
| 16:08:46 | sean-k-mooney | ignore those by the way ^ | |
| 16:09:04 | sean-k-mooney | im trying to debug stuff. | |
| 16:09:28 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Find instance in another cell during floating IP re-association https://review.opendev.org/656594 | |
| 16:09:37 | melwitt | efried: I think they should both be access_url. the second one works because it's just checking the scheme, which would be the same on both access_url_base and access_url | |
| 16:09:56 | efried | melwitt: access_url is a @property tho, not a field. | |
| 16:10:10 | melwitt | yeah, but I think you need to get the access_url first and if None, raise | |
| 16:11:02 | melwitt | that check is supposed to be checking whether there is an access_url available and the property can return None | |
| 16:11:09 | stephenfin | efried: Yeah, what melwitt is saying. I've replied on the patch | |
| 16:11:24 | melwitt | but I dunno, maybe it doesn't really matter because all that method is doing is validating the scheme | |
| 16:11:49 | melwitt | it's never going to look at anything beyond the "https" or whatever the scheme is | |
| 16:12:27 | efried | ah, that makes sense | |
| 16:12:44 | efried | arguably a bit unrelated, but sokay I guess. | |
| 16:13:32 | melwitt | yeah, I'd agree that using the actual access_url here would be unrelated to what this method is doing | |
| 16:14:08 | efried | melwitt: If you're still good, I'll +A | |
| 16:14:12 | melwitt | (realized that as I typed the next two sentences) | |
| 16:15:14 | melwitt | efried: yeah I think it's fine after thinking through | |
| 16:16:10 | efried | ack, thanks for bearing with me melwitt & stephenfin | |
| 16:16:13 | melwitt | probably did | |
| 16:16:20 | stephenfin | thanks for the review (y) | |
| 16:22:59 | efried | sean-k-mooney: can you please ack this https://review.opendev.org/#/c/680094/ ? | |
| 16:23:54 | sean-k-mooney | oh the os-vif request | |
| 16:24:02 | sean-k-mooney | yes i wanned to double check one thing | |
| 16:24:08 | sean-k-mooney | but i think its fine | |
| 16:24:16 | efried | sean-k-mooney: ...per http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009182.html | |
| 16:24:26 | efried | thank you | |
| 16:24:39 | sean-k-mooney | we did 2 train release already for m1 and m2 so this tecnically is not the first os-vif release of train | |
| 16:24:52 | sean-k-mooney | but i think 1.17.0 still make sense for other reasons | |
| 16:25:19 | efried | sean-k-mooney: right, that was the main thing I was concerned about. It looked like there were two bugfixes since the last release, but one of them seemed like it might be feature-y. | |
| 16:25:56 | efried | I'm sure it's not the end of the world if we go feature bump when we should have gone bugfix bump... is it smcginnis? | |
| 16:25:59 | sean-k-mooney | one of them was a securiy bug which has been backported | |
| 16:26:33 | sean-k-mooney | honestly version number are cheap so i would rather bump more then we neeeded too then not so 1.17 looks good to me | |
| 16:27:41 | sean-k-mooney | efried: no if we bump major it would be an issue but bumping feature should not be | |
| 16:27:56 | sean-k-mooney | stien is on the 1.15.x seriese anyway | |
| 16:28:30 | efried | I guess the only downside could be confusion of having .16 and .17 both in train. But meh. | |
| 16:28:39 | smcginnis | efried: So that one wasn't a new feature? I didn't go much further than the commit message. | |
| 16:29:15 | efried | smcginnis: the commit message sounded feature-y for sure, but there was a bug (not a bp) associated. This is what I wanted sean-k-mooney to confirm for us. | |
| 16:29:31 | efried | I could look at the code, but... | |
| 16:29:38 | efried | jangutter: you have an opinion here? | |
| 16:30:29 | efried | specifically: is this https://review.opendev.org/#/c/658786/ a "feature" or a "bugfix", for purposes of release numbering? | |
| 16:31:16 | jangutter | efried: it leans more to "feature" than bugfix, especially since the original idea was "feature". | |
| 16:31:31 | efried | jangutter: Okay, good enough for me, thanks. | |
| 16:31:37 | efried | sean-k-mooney, smcginnis: ^ cool? | |
| 16:31:48 | smcginnis | Works for me. | |
| 16:32:11 | jangutter | efried: os-vif uses bugs to track features (like neutron) | |
| 16:32:39 | efried | smcginnis: acked, thanks for your patience. | |
| 16:32:53 | efried | jangutter: okay, gtk, then I'm going to have this question every release :P | |
| 16:33:53 | jangutter | efried, sean-k-mooney: is there a way to distinguish between [RFE] bugs and your run of the mill annoyances? | |
| 16:33:58 | smcginnis | Thanks for following up on that. | |
| 16:34:39 | efried | jangutter: With careful use of tagging, I'm sure there is. You may have even had that in place in this case - I admit I didn't look. | |
| 16:34:45 | smcginnis | It's been pretty common in my experience that new "features" also fix bugs, so I've never really used BPs vs bugs as an indicator. | |
| 16:35:03 | efried | But that would also require an understanding of whatever tag scheme by whoever's doing the looking | |
| 16:35:11 | efried | and yeah, more broadly, what smcginnis says. | |
| 16:36:13 | efried | it's on a team by team basis, so really we need team members to make this call one way or another (either by proposing the release patches themselves and noting this reasoning in the commit message, or by being pestered like this when releases are proposed "automatically" or otherwise externally to the team) | |