Earlier  
Posted Nick Remark
#openstack-nova - 2026-07-16
02:56:19 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Omit optional fields for SEV/SEV-ES https://review.opendev.org/c/openstack/nova/+/994921
02:56:27 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Drop sev capability check in launch instance flow https://review.opendev.org/c/openstack/nova/+/994929
02:56:35 opendevreview Takashi Kajinami proposed openstack/nova master: AMD SEV: omit iommu='on' for virtio devices https://review.opendev.org/c/openstack/nova/+/909635
03:00:55 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-SNP memory encryption https://review.opendev.org/c/openstack/nova/+/994930
03:02:20 opendevreview Takashi Kajinami proposed openstack/nova master: compute: Validate SEV/SEV-ES support at start up https://review.opendev.org/c/openstack/nova/+/994342
03:02:25 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Ignore SEV-ES when SEV-SNP is detected https://review.opendev.org/c/openstack/nova/+/994343
03:03:04 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Detect AMD SEV-SNP support https://review.opendev.org/c/openstack/nova/+/994764
03:03:23 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Support launchSecurity element for SEV-SNP https://review.opendev.org/c/openstack/nova/+/994920
03:03:33 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Omit optional fields for SEV/SEV-ES https://review.opendev.org/c/openstack/nova/+/994921
03:03:47 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Drop sev capability check in launch instance flow https://review.opendev.org/c/openstack/nova/+/994929
03:04:02 opendevreview Takashi Kajinami proposed openstack/nova master: AMD SEV: omit iommu='on' for virtio devices https://review.opendev.org/c/openstack/nova/+/909635
03:05:17 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-SNP memory encryption https://review.opendev.org/c/openstack/nova/+/994930
03:05:21 opendevreview Takashi Kajinami proposed openstack/nova master: Update documentations for AMD SEV-SNP support https://review.opendev.org/c/openstack/nova/+/995090
03:05:28 opendevreview Takashi Kajinami proposed openstack/nova master: Remove [libvirt] num_memory_encrypted_guests https://review.opendev.org/c/openstack/nova/+/995120
03:05:35 opendevreview Takashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316
03:44:24 opendevreview Takashi Kajinami proposed openstack/nova master: Remove [DEFAULT] vcpu_pin_set https://review.opendev.org/c/openstack/nova/+/996016
08:27:18 opendevreview Takashi Kajinami proposed openstack/nova master: Remove [workarounds] disable_libvirt_livesnapshot https://review.opendev.org/c/openstack/nova/+/997492
08:27:28 opendevreview Merged openstack/nova stable/2025.1: Fix mutating global config in websocket proxy https://review.opendev.org/c/openstack/nova/+/995958
09:38:11 gibi fyi tox cover is timing out a lot recently in test_schemas I filed https://bugs.launchpad.net/nova/+bug/2160901
09:48:24 sean-k-mooney gibi: i know there was some slownees with those in the past
09:48:33 sean-k-mooney but i dont remember exactly why
09:48:43 sean-k-mooney i just recall mentioning it to stephen
09:53:33 sean-k-mooney gibi:lol we were looking at the same review
10:06:19 tkajinam :-)
10:15:46 opendevreview Balazs Gibizer proposed openstack/nova master: [cover]Disable slow test_schemas test case https://review.opendev.org/c/openstack/nova/+/997503
10:16:18 gibi I found no better way given our current cirumstances (py314+threading mode fails)
10:17:40 sean-k-mooney gibi: i think that is fien for now
10:17:52 sean-k-mooney gibi: i think the answer might be to split it into multipel tests
10:20:23 sean-k-mooney currently its looping over all our api contoler and then looping over all the route and then testing every schema in one masive test
10:20:27 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_schemas.py#L69-L123
10:20:56 sean-k-mooney gibi: the fix i think is to use subtests or ddt to split up the test per contoler or route
10:21:12 sean-k-mooney so that each schema baseiclly get mapped to its own test
10:21:52 sean-k-mooney that way we wont hit the per test timeout
10:26:50 sean-k-mooney tkajinam: speaking of masive tests that should be broken up you sev functional test have lots of repatead code that should be in shared helpers and the test shoudl be broken up in to small tests
10:26:58 sean-k-mooney tkajinam: but im not going to block on that for now
10:27:10 sean-k-mooney but we shoudl clean that up in a dedicated followup
10:29:58 gibi sean-k-mooney: yeah that is also an option
10:30:38 sean-k-mooney im also fine with not runing that in coverage
10:31:17 sean-k-mooney in this particalar case im not sure that the coverage report will matirally be any better/worse by runing that one test
10:31:34 sean-k-mooney i just think it might be nice to do that break anyway for the unit tests
10:31:45 sean-k-mooney its extra slow in cover because of the profiler overhead
10:31:59 sean-k-mooney but its still the slowest or one of the slowest unit test today
10:47:31 sean-k-mooney tkajinam: i didnt know that sev-snp actully needed sateless firmware?
10:48:57 sean-k-mooney tkajinam: is that a qemu limiation or amd one
10:51:24 sean-k-mooney ok ya that called ou tin the spec i just missed it https://specs.openstack.org/openstack/nova-specs/specs/2026.2/approved/amd-sev-snp-libvirt-support.html#:~:text=Also%20amd%2Dsev%2Dsnp%20requires%20stateless%20firmware%2C%20so%20explicit%20hw%5Ffirmware%5Fstateless%3DTrue%20image%20property%20setting%20is%20also%20required
10:59:50 tkajinam sean-k-mooney, that's the limitation enforced by qemu, and is also needed so that libvirt can pick up the appropriate ovmf file
11:00:50 sean-k-mooney ack
11:00:53 tkajinam sean-k-mooney, yeah I agree the current tests are quite redundant. I'll try refactoring these later
11:01:13 sean-k-mooney im basiclly +2w on most of your serise now ill add +w to the bottom patch when im done
11:01:36 tkajinam thanks !
11:01:51 sean-k-mooney im on the last two clean up patchs so we shoudl get this into the ci later today
11:02:05 tkajinam :-D
11:02:35 sean-k-mooney i have left some comments along the way but nothing was worth holding or respinign the patches for
11:07:31 tkajinam thanks. I'll go through these later and may address these in follow-ups
11:22:51 sean-k-mooney i think all that needed a recheck are now running https://zuul.openstack.org/status?change=994342 and all the approves are in place so im gong to go get coffee
11:39:22 tkajinam \o/
12:43:49 artpej Hi, I submitted a bug (https://bugs.launchpad.net/nova/+bug/2158443) some time ago and proposed a fix (https://review.opendev.org/c/openstack/nova/+/995073). Is there anything I'm missing to get this reviewed and integrated?
12:47:41 gibi artpej: You did the right thing
12:47:56 gibi artpej: both by filing a bug, proposing a patch, and pinging us on IRC
12:48:38 gibi unfortunately we are short staffed so not all patches get reviewed and the ones that gets reviewed might take a long time
12:53:02 gibi gmaan: when you are up, what does this schema stacking means? https://github.com/openstack/nova/blob/42fd9b6c8c5da09c92f5fb7efac1f5da52ca7df4/nova/api/openstack/compute/servers.py#L700-L702 Why do we have v20 top of an unversioned schema there?
12:53:15 gibi this is related to the fix from artpej in https://review.opendev.org/c/openstack/nova/+/995073
12:59:08 gibi it almost like that the 2.0 schema is better than the 2.0-2.18 schema. That feel backwards
12:59:19 gibi ~2.1-2.18
12:59:37 gibi artpej: at least you found something strange :)
13:01:45 artpej Yes, my users are weird people who put spaces at the beginning of security group names :)
13:05:51 gibi that is weird too :)
13:06:11 gibi but the schema handling in nova for that call is weird as well
13:06:18 gibi hence my ping to gmaan
13:07:27 gibi we should not have an API where 2.0 accepts " sg " but 2.1-2.18 does not. But 2.0 was a bit special I assume compared to 2.1. Still I feel like we might be able to say lets fix this in 2.1-2.18.
13:08:29 gibi hm
13:08:34 gibi even more weird
13:08:49 gibi it might be that only 2.0 allows leading spaces there and nothing after 2.1
13:09:13 gibi still we have a strong case, if neutron allows leading spaces then we should not stop it
13:35:17 opendevreview Merged openstack/nova master: Do not try to return empty attachment_id from API https://review.opendev.org/c/openstack/nova/+/996757
13:41:22 opendevreview Merged openstack/nova master: compute: Validate SEV/SEV-ES support at start up https://review.opendev.org/c/openstack/nova/+/994342
13:41:49 opendevreview Merged openstack/nova master: libvirt: Ignore SEV-ES when SEV-SNP is detected https://review.opendev.org/c/openstack/nova/+/994343
14:17:39 tkajinam sean-k-mooney, could you also check https://review.opendev.org/c/openstack/nova-specs/+/996394 and https://review.opendev.org/c/openstack/nova-specs/+/996395 when you have time ?
14:18:01 tkajinam these two update the sev-snp spec according to the latest implementation
14:28:06 opendevreview Takashi Kajinami proposed openstack/nova master: Do not report SEV capability for non kvm virt_type https://review.opendev.org/c/openstack/nova/+/996498
14:55:44 sean-k-mooney tkajinam: bothg of those look good to me as well
14:58:13 tkajinam sean-k-mooney, thanks !
14:59:04 opendevreview Kamil Sambor proposed openstack/nova master: Replace StaticallyDelayingWrapper with futurist DelayingExecutor https://review.opendev.org/c/openstack/nova/+/997410
15:11:30 opendevreview Merged openstack/nova-specs master: Fix SEV-SNP feature detection in start up https://review.opendev.org/c/openstack/nova-specs/+/996394
15:13:34 opendevreview Merged openstack/nova-specs master: Use domain capability to detect SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/996395
16:00:38 gmaan gibi: artpej: that seems strange as v2.0 is less strict than >=v2.1 and not other way. anyways I will check it today
16:13:09 gibi gmaan: thanks
16:35:50 opendevreview Balazs Gibizer proposed openstack/placement master: Check overall capacity before generating candidates https://review.opendev.org/c/openstack/placement/+/997617
16:36:24 gibi sean-k-mooney: it is not terrible to check the flattened capacity in python ^^
16:36:49 sean-k-mooney cool
16:36:59 sean-k-mooney i mean if we get it workign we can make it faster later
16:39:33 gibi it works and it is not super ugly as I had all the data available in the right place, it is just a bit of data juggling to summarize and compare
16:39:56 sean-k-mooney ack, on a call but ill look after
16:40:05 gibi thanks
16:40:25 sean-k-mooney if its "good enough" then we can start there and defer doign it in sql till later
16:41:32 sean-k-mooney oh your system how long these it take i assume you updated the coments in the tests?
16:42:50 gibi it is so fast that I bumped N to 64 and removed the comments as it runs in sub seconds
16:43:13 gibi it fully eliminates the hot path
16:43:36 gibi I also added a test that shows the the extra check is not too costly for the non edge case
16:44:05 gibi {3} placement.tests.functional.test_allocation_candidates.TestAlmostFittingRoot.test_one_less_device_than_requested_no_wide_tree_optimization [0.231623s] ... ok

Earlier   Later