Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-04-03
16:50:50 melwitt I'll adjust things based on your comments. I haven't really done a func test like this before where it is more about checking the state of a resource in a different component, so I may have done it not the best way
16:51:36 sean-k-mooney well i think yoru test is fine. i just know that we have had issues with retry loops in fucntional tests before
16:51:49 sean-k-mooney so if we can force the ordering more explcitly that can help
16:52:10 sean-k-mooney ill let this run for a while and if it passes 50-100 times its proably ok
16:52:49 sean-k-mooney i think we can impove things if we reuse some of the helpers but im no tsure we strictly need too for this to prove what it needs too
16:53:36 sean-k-mooney ya the cidner fixutre behvaior is a litttel odd in places
16:53:50 sean-k-mooney but its also non trivial to emulate os im not really surpised
16:54:24 sean-k-mooney melwitt: ah https://review.opendev.org/c/openstack/nova/+/919979/4/nova/tests/functional/integrated_helpers.py
16:54:56 sean-k-mooney i _attch_volume for my multi attach repoducer
16:55:01 melwitt yeah I think my concern with it is if it could possibly "skip" the status "detaching" due to timing differences. so I won't be surprised if need to do the wait a different way
16:55:12 sean-k-mooney i was very confused why i did nto find it when i went looking
16:56:29 sean-k-mooney melwitt: so there are some exmples form gibi useing treading.event
16:56:36 sean-k-mooney to get thisn to pause in a specific state
16:56:41 melwitt oh my bad, I either didn't see that or there was some reason it didn't work for me and I forgot. but more likely the former
16:56:42 sean-k-mooney mainly for networking i think
16:57:01 sean-k-mooney no _attach_volume is not merged
16:57:12 sean-k-mooney its in that other volume serises i mentioend to you that i need to respine
16:57:38 melwitt when I first started this test I used libvirt func test base which super did not work and is not needed anyway and I changed it
16:57:40 melwitt oh haha ok, didn't realize that was an unmerged patch
16:58:07 sean-k-mooney so i last worked ont hat patch 6 months ago so in my brain its totally merged
16:58:31 melwitt :)
16:58:40 sean-k-mooney but i keep not geting around to rebaseing it
17:00:13 sean-k-mooney melwitt: so this is what i was referint too https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_2085975.py
17:00:30 sean-k-mooney using trheading event to allow use to pause thing in speciifc places
17:00:42 melwitt ah ok, thanks
17:01:43 sean-k-mooney that might not be appliable to this case but its ther if you thing it would be useful basicly you woudl set the evnet in the palce your raising
17:02:09 sean-k-mooney and we woudl wait on it were we currently have the retry loop
17:02:50 melwitt gotcha. yeah that might be nicer
17:03:15 sean-k-mooney ======
17:03:17 sean-k-mooney Totals
17:03:19 sean-k-mooney ======
17:03:21 sean-k-mooney Ran: 100 tests in 700.9413 sec.
17:03:23 sean-k-mooney - Passed: 100
17:03:25 sean-k-mooney - Skipped: 0
17:03:27 sean-k-mooney - Expected Fail: 0
17:03:29 sean-k-mooney - Unexpected Success: 0
17:03:31 sean-k-mooney - Failed: 0
17:03:33 sean-k-mooney Sum of execute time for each test: 353.3871 sec.
17:03:35 sean-k-mooney i mean it seam to work as it is
17:03:37 sean-k-mooney so im less concerned now
17:05:54 melwitt yeah I think what could mess it up is if the timing was sufficiently bad, like what if the _wait got delayed due to CI node busyness and it misses the intermediate state of "detaching". so I think you're right there is some instability possible there
17:06:26 sean-k-mooney ya it could happen. we could rehceck it once or twice
17:06:42 sean-k-mooney its a test only change so it does not run tempest
17:06:47 sean-k-mooney so rechecking is cheap
17:06:52 melwitt yeah. I'll try the event thing. oh right
17:07:43 sean-k-mooney ack, no worreis if you dont hcange it. i upgraded to +2 and rechecked
17:07:50 melwitt and also I was thinking future failures after it merged
17:07:51 sean-k-mooney if we recheck once more after that
17:07:58 sean-k-mooney i think we are good
17:08:15 sean-k-mooney ya its the future case that i was thinking of
17:08:25 sean-k-mooney we have loops like this today
17:08:30 sean-k-mooney but we have had issues with them too
17:08:45 sean-k-mooney so im alwasy cautious when adding more
17:08:55 melwitt yeah. also probably wastes some time due to the loop
17:09:52 sean-k-mooney technially yes but its 3.5 seccond pretty reliably on my laptop
17:09:58 sean-k-mooney not amazing but not terrible
#openstack-nova - 2025-04-04
07:24:42 zigo FYI, we were affected by nova-compute flapping, we applied https://review.opendev.org/c/openstack/nova/+/939317 and that solved the issue for us. Thanks to melwitt and others who worked on it.
08:06:39 opendevreview Masahito Muroi proposed openstack/nova master: Use dict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/939658
13:04:38 sean-k-mooney dansmith: i feel like you will care about https://etherpad.opendev.org/p/nova-2025.2-ptg#L577
13:04:45 sean-k-mooney wel have an opionion
13:05:19 sean-k-mooney care implies a positive emotional sentement that i dont think you will express toward the idea
13:06:43 sahid o/
13:07:35 sahid We don't have any logs in scheduler to give some information regarding the how the list is re-ordered by weighter
13:08:22 sean-k-mooney we do at debug
13:08:29 sean-k-mooney we have the weights per host
13:08:43 sean-k-mooney per weigher
13:36:07 dansmith sean-k-mooney: that line is blank, which thing?
14:00:17 frickler hmm, the timeslider sadly doesn't show line numbers. the line's now at #578 now, though
14:00:49 sean-k-mooney dansmith: I would quite like an equivalent to oVirt's VDSM hooking mechanism in Nova.
14:01:16 sean-k-mooney i.e. the requst to have a way to add arbiatry hooks to modify the libvirt xml without chanign nova
14:01:18 dansmith sean-k-mooney: okay I figured that might be it :)
14:03:24 dansmith bauzas: any chance you could try to review some of this OTU series? https://review.opendev.org/c/openstack/nova/+/944148
14:03:37 dansmith the bottom two are just trivial setup for the larger one above
14:03:39 bauzas_ dansmith: I definitely want to
14:03:57 dansmith all of them are +2 already, so the bottom two could probably be sent to the gate without a lot of time investment :)
14:03:58 dansmith thanks
14:43:59 sean-k-mooney dansmith: +2w on the first patch +2 on the second with a question https://review.opendev.org/c/openstack/nova/+/944149/comment/133f1fc5_dabaf92d/
14:44:29 sean-k-mooney im going ot grab somethign to drink and kick off a devstack install but ill try and take a look at the rest when i get back
14:44:54 dansmith sean-k-mooney: please see response
14:45:17 dansmith https://review.opendev.org/c/openstack/nova/+/943816/12/nova/compute/pci_placement_translator.py specifically L202 here :)
14:51:26 sahid sean-k-mooney: We don't have any logs like for filters. Filter Computefilter returned 2 host(s) I could be good to know the weighter as-well. Exemple I have removed one of them and I have no idea whether it is well removed or not
14:52:39 sahid I can see a ligne WeighedHost but no detail about which weighter was used to order the list
15:11:37 sean-k-mooney sahid: https://zuul.opendev.org/t/openstack/build/95c4e84b168d4a79ba750797f28a81c7/log/controller/logs/screen-n-sch.txt#1010
15:12:07 sean-k-mooney we have output per weigher per host both pre and post normaization and multiplying
15:12:41 sean-k-mooney sahid: again only at debug level like the filters
15:13:02 sean-k-mooney grep for "DEBUG nova.weights" in yoru logs
15:15:51 sean-k-mooney https://github.com/openstack/nova/blob/9d910ec4bf2a12baf3b5f0ec3bc41686413538fb/nova/weights.py#L136-L170
15:16:15 sean-k-mooney sahid: it was added 4 years ago https://github.com/openstack/nova/commit/154ab7b2f9ad80fe432d2c036d5e8c4ee171897b
15:17:19 sean-k-mooney dansmith: that not what i was asking let me restate it
15:17:37 dansmith oh? okay
15:17:56 sean-k-mooney dansmith: do we need to invaliate the cache for all pci in placement RPs or just the one that also are marked OTU
15:18:12 sean-k-mooney for normal devies we do not expect the reserved to change
15:19:02 dansmith sean-k-mooney: ah, so if you look at some of gibi's comments on the commit message, he noted that PCI-in-placement specifically calls out reserved as a thing that could be changed by the operator directly in placement,
15:19:40 dansmith and as such it's probably good that we invalidate our cache for all of those to make sure we're seeing the right info, even though technically only OTUs care at the moment
15:19:44 sean-k-mooney oh it does? ok i dont know why but if that the exsign bevhiaor then the code you wote makes sense
15:20:15 dansmith sean-k-mooney: yeah he provided a link to a comment in the code that specifically says that, and asked for me to add words to the commit message about it
15:20:31 sean-k-mooney i dont knwo what the orginal usecase for allowing the reserved to be change was but if thats the case then il upgrade to +w
15:21:00 dansmith so we _could_ potentially follow up with this and use the OTU trait as well to control invalidation, but I think he would argue it's best if we just don't so that future developers are clear that we won't get stuck in the same way I initially did until I added this :)
15:21:04 sean-k-mooney ah https://review.opendev.org/c/openstack/nova/+/944149/6//COMMIT_MSG#15
15:21:22 sean-k-mooney ok i missed that when i looked at the comit

Earlier   Later