| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-06 | |||
| 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) | |
| 16:37:15 | sean-k-mooney | jangutter: we use RFE bugs in os-vif to track feature | |
| 16:37:26 | sean-k-mooney | jangutter: because we dont want to have to use specs or blueprints | |
| 16:37:40 | sean-k-mooney | so RFE bugs cant be backported as they are features | |
| 16:37:43 | sean-k-mooney | other then that no | |
| 16:40:04 | efried | aspiers: I'm looking at https://review.opendev.org/#/c/680065/8/nova/tests/unit/scheduler/test_utils.py -- I was digging for this answer myself, but am being pulled in multiple directions -- can you confirm that there are other tests covering the behavior when hw_machine_type is absent (which is to allow it through) ? | |
| 16:40:19 | efried | I think tests above those are doing it, yah? | |
| 16:40:25 | aspiers | efried: checking | |
| 16:41:03 | efried | iow I wanted to say "hey, instead of doing this to all three, just do it to one or two, so it proves the other thing" -- but don't want to block on that if other tests are already covering that. | |
| 16:41:06 | aspiers | efried: testing hw_machine_type being absent was missing until very recently, I just added it like 2 days ago | |
| 16:41:15 | aspiers | let me find where | |
| 16:41:23 | aspiers | it's mentioned in a commit message somewhere | |
| 16:41:46 | aspiers | oh yeah it's this review | |
| 16:42:07 | aspiers | let me find the lines | |
| 16:42:35 | aspiers | efried: https://review.opendev.org/#/c/680065/8/nova/tests/unit/virt/test_hardware.py@3837 | |
| 16:43:09 | efried | that's asserting failure due to no uefi... | |
| 16:43:14 | aspiers | doh | |
| 16:43:19 | aspiers | brain fried | |
| 16:43:23 | efried | where's a case that succeeds with no mach type | |
| 16:43:31 | aspiers | ah OK | |
| 16:43:45 | aspiers | checking | |
| 16:43:55 | efried | perhaps L3926 could have a None in it too? | |
| 16:44:09 | aspiers | ah that has to be tested in the driver | |
| 16:44:20 | aspiers | since with no machine type in the image, it relies on pulling it from utils | |
| 16:44:28 | aspiers | which reads nova.conf on compute node | |
| 16:44:36 | aspiers | I think it's maybe in a later patch | |
| 16:44:39 | aspiers | checking ... | |
| 16:46:58 | aspiers | efried: https://review.opendev.org/#/c/644565/52/nova/tests/unit/virt/libvirt/test_driver.py@2700 | |
| 16:47:21 | aspiers | although maybe there is a test missing for when CONF.libvirt.hw_machine_type is set to x86_64=q35 | |
| 16:47:58 | efried | aspiers: that one is *also* a failure scenario | |
| 16:48:05 | aspiers | yeah that's what I'm saying | |
| 16:48:23 | aspiers | CONF.libvirt.hw_machine_type set to x86_64=q35 would be the non-failure scenario | |
| 16:48:27 | aspiers | I can add that | |
| 16:48:48 | aspiers | efried: kudos for eagle eyes as usual :) | |
| 16:49:07 | efried | where are you going to add it? | |
| 16:50:25 | efried | aspiers: is it adequate to undo one of those three lines of delta here https://review.opendev.org/#/c/680065/8/nova/tests/unit/scheduler/test_utils.py ? | |
| 16:50:37 | efried | and then maybe also add the case next to the one in the fourth patch? | |
| 16:51:35 | efried | aspiers: there's one more comment in there, in case you agree and want to make that change at the same time. | |
| 16:51:46 | aspiers | efried_afk: ok thanks! | |
| 17:45:31 | mriedem | dansmith: so linkedin told me it was a big day for you and i was looking at the suggested comments and i thought this one was a good fit https://photos.app.goo.gl/WrC1wjQYu7Btfz2g8 | |
| 17:48:10 | dansmith | heh | |
| 17:48:21 | dansmith | yeah, I wish linkedin wouldn't ask people to do that | |
| 17:48:34 | dansmith | and/or I wish people would ignore all that crap like I do :) | |
| 17:49:55 | sean-k-mooney | i think mose people do | |
| 17:50:35 | aspiers | haha | |
| 17:51:01 | sean-k-mooney | dansmith: the real question is does it feel like 6 or 12 | |
| 17:51:25 | dansmith | sean-k-mooney: see, you're doing it, although indirectly :) | |
| 17:55:25 | mriedem | i just laugh at the AI/ML generated auto responses | |
| 17:55:34 | mriedem | i hate them on my phone but am too lazy to figure out how to disable | |
| 17:55:50 | mriedem | because no my every response to my wife's text messages shouldn't be, "I know, right?" | |
| 17:56:31 | melwitt | I know that you can disable profile updates from notifying the world but I don't know if that encompasses work anniversaries too | |
| 17:56:55 | mriedem | heh, messaging > settings > smart reply (disable) | |
| 17:56:57 | mriedem | that was easy | |
| 17:57:08 | mriedem | "I know, right?" | |
| 18:05:06 | sean-k-mooney | ok i havent got anything useful done in an hour some im goign to get dinner. i might be back online later. if not have a nice weekend o/ | |
| 18:05:50 | dansmith | sean-k-mooney: it's friday. turn. off. the. laptop. | |
| 18:13:36 | mriedem | but is bauzas still up working on a friday night? | |
| 18:13:45 | mriedem | b/c i'm +2 on https://review.opendev.org/#/c/680394/4 and the 2 above it | |
| 18:16:46 | mriedem | gibi: when you're back and collecting comments, i approved but left a comment about defining constants for https://review.opendev.org/#/c/655109/24 | |
| 18:27:51 | mriedem | if anyone is adventurous, there are +2s waiting for a +W on 4 of the bw provider move series https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports+status:open+label:Code-Review=2 | |
| 18:28:17 | mriedem | they are all about min compute service version checking and functional tests | |
| 18:28:19 | mriedem | so pretty easy | |
| 18:28:46 | mriedem | the bottom one is only big b/c of a lot of test coverage | |
| 18:38:40 | mriedem | dansmith: so i've got an rpc compat thing i'd like to remove but need to get out of my head, | |
| 18:39:23 | mriedem | before this change, https://review.opendev.org/#/c/582417/ conductor would always send a legacy request spec dict to compute's prep_resize method during cold migrate/resize and compute would never send it back to conductor on reschedule, | |
| 18:39:39 | mriedem | with that change, prep_resize on the comput takes a RequestSpec object if you're not pinned | |
| 18:39:49 | mriedem | and compute passes back whatever it gets | |
| 18:40:15 | mriedem | there were no changes to the conductor compute task api rpc interface b/c it always took a request spec and passed it through (for the api calling conductor initially) | |
| 18:40:35 | mriedem | what i'd really like to do is remove this compat code when compute doesn't send a request spec back on reschedule https://review.opendev.org/#/c/582417/7/nova/conductor/manager.py | |
| 18:41:07 | mriedem | which should be possible if we aren't supporting older-than-stein computes in train or ussuri, | |
| 18:41:15 | dansmith | violates the rpcapi though | |
| 18:41:22 | mriedem | where i think i f'ed up was that the compat code in conductor isn't handling request spec being a dict | |
| 18:41:46 | mriedem | no i don't think it violates the rpc api because there was no change to the conductor rpc api to remove the request spec that compute passes back | |
| 18:41:50 | mriedem | it's just a pass through | |
| 18:41:55 | mriedem | the only interface that changed was the compute rpc api | |
| 18:42:15 | dansmith | the object could be None there which means old version right? | |
| 18:42:15 | mriedem | so the only time compute won't send a request spec back up is if it's pre-stein | |
| 18:42:36 | mriedem | well, if you're pinned to less than conductor 1.13 yeah... | |
| 18:42:58 | dansmith | right | |
| 18:43:09 | mriedem | which was mitaka https://review.opendev.org/#/c/277800/ but yeah | |
| 18:43:15 | dansmith | so you can't remove the ability to take an N.0 call unless you bump majors | |