Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-04-03
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
15:22:03 gibi sean-k-mooney: the idea behind it is that nova should own as small part of the inventory as it cares about. Before OTU it only cared about total and max_unit (as it is mandatory) so the rest of the field was never set in the inventory of a PCI RP
15:22:09 gibi making it possible to set externally
15:22:14 sean-k-mooney dansmith: well as we dicussed a few weeks ago im not really sure why we are caching at all
15:22:25 sean-k-mooney so im all for being safe with correctness here
15:22:32 sean-k-mooney even if it might be slightly slower
15:23:00 sean-k-mooney gibi: right and nova cares about reserved even without OTU
15:23:08 sean-k-mooney we report the inventory based on the devspec
15:23:15 dansmith well, for a big tree of lots of providers it probably is a real gain, but brings problems like this (as does all caching of course)
15:23:29 sean-k-mooney so you shoudl never be chanign reserved since that will mnake placement and the pci deivces tabel be sort of out of sync
15:24:32 sean-k-mooney anywya dont wnat ot boil the ocean i was just wonderigy why we were not checkifn for "is pci in placement and one time use" rather then just "is pci in placment"
15:25:20 dansmith well, that patch is before OTU, so that's part of why :)
15:26:08 sean-k-mooney ya i was orgianly wondering if that was the reason nad if you were going to modify it again in the next patch
15:26:10 dansmith nova is not currently reporting anything reserved for pci-in-placement providers, AFAIK (other than OTU in the next patch), so I think gibi's point is that if you want to reserve some VFs you would do it in placement directly
15:26:23 dansmith sean-k-mooney: yeah I understand now, I just didn't get that from your comment :)
15:27:54 sean-k-mooney no worries. so +2w on the first too. ill take a look at the rest once i have devstack deploying
15:28:01 dansmith thanks
15:33:24 sean-k-mooney dansmith: as an aside, you have a vexhost lable created have you tried to use this in ci yet?
15:40:01 sean-k-mooney so the host im using is not the one that has igb support. you said in your testing the rng didnt crash the host vm?
15:40:17 sean-k-mooney if so ill see if i can ply with that as well
15:49:39 dansmith (on a call)
16:03:43 melwitt zigo: just fyi that we had a partial regression involving mdevs with that patch which was tracked and fixed here https://bugs.launchpad.net/nova/+bug/2098892
16:21:01 sean-k-mooney dansmith: not urgent but you have a trival bug in the unit test. https://review.opendev.org/c/openstack/nova/+/943816/comment/4d20bb05_6116bff7/ it does no tactully break anything so it can be a follow up
16:26:36 dansmith sean-k-mooney: ah yeah will fix in a follow up..
16:27:34 sean-k-mooney your not actully building it into a treee or populating the pci tracker so technically it wont break anything. it just will be confusing if we read it in like a year so ya no need to respine but nice to fix
16:28:55 dansmith yep, spinning a follow-up now
16:29:03 dansmith sean-k-mooney: are you holding the +W until you test locally?
16:29:44 dansmith oh nm :)
16:30:01 sean-k-mooney i was until my devstack failed for the 3 time
16:30:08 dansmith heh
16:33:57 sean-k-mooney there is a patch sitting in ci to make our new prometous plugin not fail if /etc/promethous exists and i keep forgetting i need to delete the dir before i restack
16:34:57 sean-k-mooney i should just checkout the fixed version but im manually testing a docs change for the default local.conf
16:36:03 sean-k-mooney * default of watcher + promethous

Earlier   Later