Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-06
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 mriedem so the only time compute won't send a request spec back up is if it's pre-stein
18:42:15 dansmith the object could be None there which means old version right?
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
18:43:26 dansmith I mean,
18:43:26 mriedem right so conductor 2.0 to make request spec required and RequestSpec object
18:43:41 dansmith I realize other shit will break if you go that old, but either we stick to these rules or we don't
18:43:47 mriedem yeah
18:44:11 mriedem i just came across that todo while reviewing gibi's series and though i'm glad we have that, and was going to remove the compat, but then realized i can't
18:44:38 mriedem so i'll be amending that todo comment i guess since i don't feel like taking on a conductor 2.0 bump
18:45:27 dansmith aye
18:51:33 openstackgerrit Merged openstack/nova master: objects: Remove ConsoleAuthToken.to_dict https://review.opendev.org/652970
19:25:07 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle legacy request spec dict in ComputeTaskManager._cold_migrate https://review.opendev.org/680762
19:25:09 mriedem ok i think that handles both issues (bad comment and dict compat)
19:34:18 openstackgerrit Merged openstack/nova master: Bump min for oslo.service & .privsep to fix SIGHUP https://review.opendev.org/679974
19:40:25 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup request spec handling in _cold_migrate https://review.opendev.org/680763

Earlier   Later