| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-26 | |||
| 09:19:59 | opendevreview | Kamil Sambor proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | |
| 09:43:43 | ralonsoh | Hi folks, quick question, if you know how to do it and if it is possible. Can Nova serve the metadata compressed? Context: https://bugs.launchpad.net/neutron/+bug/2120723 | |
| 09:47:29 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Fix the help for hw:cpu_policy flavor extra spec https://review.opendev.org/c/openstack/nova/+/958524 | |
| 10:51:22 | sean-k-mooney | ralonsoh: not that im aware of, althoguh technically if your runing the wsgi applcaition under apache or similar it can add compressions | |
| 10:51:34 | sean-k-mooney | ralonsoh: we do not have code to compress it in nova itslef | |
| 10:51:47 | sean-k-mooney | but apache or nginx coudl do it | |
| 10:52:17 | sean-k-mooney | if it did that would be refected in headers in the reponce | |
| 10:53:44 | sean-k-mooney | if they are going via a loadblancer like haproxy that could also do compression tecnially btu i dont think that would be typical. | |
| 10:54:11 | sean-k-mooney | ralonsoh: my advice wodl be do not treat it as text but a binary string | |
| 10:54:23 | ralonsoh | sean-k-mooney, yeah, the problem is the metadata proxy in neutron | |
| 10:54:37 | ralonsoh | we are doing exactly that: treating the http content as text | |
| 11:13:04 | elodilles | sean-k-mooney: i've looked at the watcher release patch and i have a question there: https://review.opendev.org/c/openstack/releases/+/958468 | |
| 11:19:28 | sean-k-mooney | elodilles: replied its technically a bugfix bump not a patch bump but i can elevate it to a Feature/Minor bump if you like | |
| 11:19:42 | sean-k-mooney | the external api behavior should remain effectivly the same | |
| 11:20:20 | sean-k-mooney | i added translation code to make swap effectivly be migrate so even if you request swap it will now use migrate and be semanticly the same effect | |
| 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: 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 | |