Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-08-26
11:20:54 sean-k-mooney elodilles: but i dont have a stong prefernce here so if you would like me to respin i can do that quickly just let me know either way
11:21:37 elodilles sean-k-mooney: neither have i :)
11:22:30 sean-k-mooney shall i update to minor? it will take like 5 mins
11:22:49 sean-k-mooney otherwise ill go back to code reivew :)
11:24:50 elodilles sean-k-mooney: i've upgraded to +2 then, but feel free to edit if you changed your mind o:)
11:27:28 sean-k-mooney we have elevated other secuirty patches to feature bumps in the past os for visiblity im torn. bugfix patches everyone shoudl basiclly take sometime folks are less inclined to take minor bumps but i still have the change open in emacs so let me quickly edit it and ill update teh commit message too
11:29:52 priteau Hello. Sorry to bother you again, we're still looking for approval for these stable backports: https://review.opendev.org/c/openstack/nova/+/945098 and https://review.opendev.org/c/openstack/nova/+/945099
11:33:19 sean-k-mooney elodilles: updated
11:33:54 sean-k-mooney priteau: sure no worries i keep opening those and not finsihing revieing them ill do it now
11:37:00 elodilles sean-k-mooney: +2'd, thanks!
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: api: Only apply "soft" additionalProperties validation to requests https://review.opendev.org/c/openstack/nova/+/952936
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
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 dansmith yeah, I see, but .. I'm not sure that's right
14:36:22 bauzas NOVA_ENABLE_UPGRADE_WORKAROUND is the tempest flag if I'm not mistaken
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 sean-k-mooney i was talking to gmann about this at one point
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: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

Earlier   Later