| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-06 | |||
| 15:47:47 | mriedem | i'm auto delegating efried delegating that to me | |
| 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 | mriedem | he only speaks that langauge | |
| 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: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 old lable https://review.opendev.org/680739 | |
| 16:08:37 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] testing with new lable. https://review.opendev.org/680738 | |
| 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. | |