Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-08-26
11:39:17 sean-k-mooney priteau: elodilles i have +2w'd the 2024.2 version and +2'd the 2024.1 version of those so once the former merges elod can upgrade there +1 on the latter and merge them
11:42:04 elodilles ACK, i'll take an eye on it
11:47:20 sean-k-mooney general quetion for folks. how woudl people feel about have ing "meta traits" taht are reported if an only iff all the cpu feature flags for x86-64 version profile are met
11:47:22 sean-k-mooney https://en.wikipedia.org/w/index.php?title=X86-64§ion=20#Microarchitecture_levels
11:48:20 sean-k-mooney basiclly the libvirt driver would addtionally report x86-64-v2 if all of the cpu feature flags requried for that were actully supported
11:48:31 sean-k-mooney same for v3 and v4
11:49:13 sean-k-mooney that would mean if you had a rhel 10 iamge for example that can only run on v3 you coudl do a singel required trait x86-64-v3
11:49:40 sean-k-mooney instead of listing all of the v3 ones indeviually
11:51:31 sean-k-mooney you could go one step futher and supprot defining meta traits in placement directly so you would not need to report them but coudl request them and it do the translation internally
11:52:00 sean-k-mooney that could be very useful eventually but i am not sure i want to go that far right now
11:53:48 sean-k-mooney how that woudl work would be creatign a new api to define a meta traits as a union of other triaits (possible even a set of requried/forbiden triat instead of a plain union of required) and placement woudl just pre process the allocation candiate string and replace any meta taits with the expanded set
11:54:37 sean-k-mooney that woudl allow admins to defien there own but im not sure we need that level of flexablity
12:12:41 opendevreview Merged openstack/nova stable/2024.2: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/945098
12:55:09 opendevreview Stephen Finucane proposed openstack/nova master: api: Separate volume, snapshot and volume attachments https://review.opendev.org/c/openstack/nova/+/952347
12:55:10 opendevreview Stephen Finucane proposed openstack/nova master: tests: Use valid UUIDs for cinder resources https://review.opendev.org/c/openstack/nova/+/952935
12:55:10 opendevreview Stephen Finucane proposed openstack/nova master: api: Only apply "soft" additionalProperties validation to requests https://review.opendev.org/c/openstack/nova/+/952936
13:00:42 stephenfin sean-k-mooney: Those functional tests are fixed now, if you're game to re-apply your +2/+W? ^
13:02:16 sean-k-mooney done ill let gmaan hit https://review.opendev.org/c/openstack/nova/+/952347/9 but the next 2-3? have +2w
13:02:26 opendevreview Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584
13:03:02 sean-k-mooney as we dicussed offline once that batch is in we can see if you need to rebase the rest or if they will just apply
13:57:56 opendevreview Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584
14:12:57 opendevreview Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584
14:30:49 bauzas dansmith: can you just +2/+W that very old Flamingo patch that modifies the support envelope for our non-SLURP release ? https://review.opendev.org/c/openstack/nova/+/944018
14:30:56 bauzas this is too way overdue
14:32:32 dansmith bauzas: I thought we were sticking with two releases always to make sure we always support skip-level?
14:33:07 bauzas nope, we always set the minimum object version to N-1 if we are on a non-SLURP as we don't support skip-level for ops
14:33:21 dansmith ...but we run grenate-skip-level-always
14:33:35 dansmith I'm not sure why that didn't fail though (logs are gone)
14:33:37 bauzas indeed, but that's again not our support envelope
14:33:49 bauzas skip-level changes the option and bypasses that value then
14:33:58 dansmith does it?
14:34:00 bauzas (IIRC)
14:34:19 bauzas yeah, IIRC we have a flag that says "I gonna skip the min version"
14:34:26 bauzas for something we called FFU way long before
14:34:43 bauzas the beast is gone but the flag remains
14:34:44 dansmith if so I don't know where that is
14:35:31 bauzas https://review.opendev.org/c/openstack/nova/+/913890 was the one we merged for Dalmatian
14:36:22 bauzas NOVA_ENABLE_UPGRADE_WORKAROUND is the tempest flag if I'm not mistaken
14:36:22 dansmith yeah, I see, but .. I'm not sure that's right
14:38:07 bauzas https://opendev.org/openstack/grenade/src/branch/master/projects/60_nova/upgrade.sh#L77
14:38:20 dansmith I'm not sure skip-level-always actually does a multinode and leaves a node behind.. from the code I don't see how this would not break a skip level
14:38:22 bauzas that's the thing we did from Antelope and older
14:38:41 bauzas skip-level was turning the object version check off
14:39:02 bauzas but we always said that our support envelope was N-1
14:39:05 bauzas for non-SLURP
14:39:16 dansmith okay, I see yeah
14:39:17 bauzas I even wrote that big fat comment in the object
14:40:28 bauzas some day around early october after we branch RC1, we would keep the value of that object
14:40:42 bauzas as we would continue to support Epoxy
14:40:50 dansmith yes there's a big comment, but it doesn't cover the skip-level detail
14:40:53 bauzas even if master is Gazpatcho-based
14:41:25 dansmith while I was grepping through the tree, my shell was reminding me that I have run some of the same greps in the last year, so clearly I was doing the same thing last time ;)
14:41:26 bauzas I can add some extra paragraph that would mention that that value is not read by skip-level
14:41:54 bauzas as skip-level turns on [workarounds]/disable_compute_service_check_for_ffu
14:42:19 bauzas lemme then amend my patch and add that comment to prevent another brain cycle next time :)
14:43:01 dansmith yeah just mentioning the config option might be enough
14:52:49 opendevreview Sylvain Bauza proposed openstack/nova master: Update min support for Flamingo https://review.opendev.org/c/openstack/nova/+/944018
14:53:52 bauzas dansmith: can you just reapply your +W ?
14:54:19 dansmith done
14:55:20 bauzas thanks
15:00:37 dansmith gibi: I don't have anything proposed but unmerged for precache
15:00:44 gibi ack
15:00:57 gibi I will test a bit manually the eventlet removal change then
15:01:01 dansmith _probably_ because we can't externally validate it, we could only make sure it didn't fail the call or something
15:01:01 sean-k-mooney i was talking to gmann about this at one point
15:01:18 gibi dansmith: ahh good point. Maybe whitebox then...
15:01:20 sean-k-mooney about maybe adding a whitebox test to ssh in and assert the base image is created after caching
15:01:27 dansmith yeah
15:01:32 sean-k-mooney i dont know if they wrote that test yest hwoever but let me look
15:02:47 gibi I don't see anything in whitebox either
15:03:05 sean-k-mooney no i don tthink they started on it
15:03:28 sean-k-mooney we were chating about it in the context of dicussiong what ci coverage we had in general when they joined the team
15:03:30 gibi OK. manual testing then... I anyhow wanted to test two different caching running in paralle
15:04:08 dansmith that might be hard unless you have a large image or artificially slow it down
15:04:17 sean-k-mooney it would be nice to add a test for it to whitebox eventually
15:04:41 gibi sean-k-mooney: I agree
15:04:53 gibi dansmith: yepp I will do one or the other :)
15:05:32 sean-k-mooney so gmaan recently added a test for booting form an iso to validate that https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/955950/4/whitebox_tempest_plugin/api/compute/test_iso_image.py
15:05:58 sean-k-mooney so we already have a custom image file in ci we could use
15:06:19 sean-k-mooney i.e. we can create a new imag e in the test in clance using the iso
15:06:37 sean-k-mooney and the pre cache that to an aggreate
15:10:19 gibi cool
15:11:32 gmaan gibi: sean-k-mooney this is where I added Core-14.0.iso image in job and devstack download it and tempest plugin can play with that image from file locattion - https://github.com/openstack/whitebox-tempest-plugin/blob/master/.zuul.yaml#L72C206-L72C219
15:13:33 gibi thanks
15:14:29 sean-k-mooney we could also have used any of the sandard images like cirros but since whitebox now expect an iso at least to run that test we might as well use it esplciy since we are intenallysuing tiny core which as the name implies is small
15:15:06 sean-k-mooney i want to revive the idea of running a subset of whitebox in nova's check jobs at somepoint by the way
15:15:08 gmaan yeah, that is not too large but we can add larger image here
15:15:34 sean-k-mooney we can skip all the ahrdware specfic stuff but obvioulsy but this and the iso but check woudl be nice to have
15:15:50 gmaan only tricky part of ssh into server booted from iso image. But i do not think pre-cache image test need that
15:16:18 sean-k-mooney we are also not doing that in whitebox today for the iso case
15:16:26 gmaan sean-k-mooney: good idea, I can add that or maybe we can run a separate peroidic job as full whitebox plugin
15:16:52 gmaan I mean running iso image test in nova
15:17:15 sean-k-mooney i spoke to melwitt breifly about changing nova-ovs-hybird plug in to nova-alt-config adn having it test more things
15:17:34 sean-k-mooney so rather then adding a new job or continuing to extend nova-next i woudl put it in that job
15:18:09 sean-k-mooney we can chat about that in more detail after FF ro at teh ptg whenever we have tiem to plan that out
15:18:31 sean-k-mooney but i was chatting to her about enableing nova on nfs and cinder nfs in that job
15:18:39 sean-k-mooney so we have coverage of both goign forward
15:19:26 sean-k-mooney so nova-alt-config woud test spice, ml2/ovs, nfs and whitebox things
15:19:43 sean-k-mooney on debian 13
15:20:01 sean-k-mooney so it will also test python 3.13

Earlier   Later