| opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | 01:02 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | 01:02 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | 01:02 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | 01:02 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | 01:16 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | 01:16 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | 01:16 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | 01:16 |
| *** mhen_ is now known as mhen | 01:17 | |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | 01:20 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | 01:20 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | 01:20 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | 01:20 |
| opendevreview | Merged openstack/nova master: Remove logic for unsupported old libvirt/qemu https://review.opendev.org/c/openstack/nova/+/952318 | 04:43 |
| opendevreview | Merged openstack/nova master: libvirt: Get info with abs path, rebase with rel path https://review.opendev.org/c/openstack/nova/+/955039 | 04:50 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix 'nova-manage image_property set' command https://review.opendev.org/c/openstack/nova/+/946733 | 04:54 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix concurrent migration of vms with multiattach volume failure https://review.opendev.org/c/openstack/nova/+/872278 | 04:57 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix instance vm_state during shelve https://review.opendev.org/c/openstack/nova/+/934294 | 05:02 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Update the api-ref for unshelve https://review.opendev.org/c/openstack/nova/+/938054 | 05:11 |
| opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | 05:26 |
| opendevreview | Merged openstack/nova stable/2025.1: Don't reset port dns_name when shelving instances https://review.opendev.org/c/openstack/nova/+/956216 | 05:26 |
| opendevreview | Merged openstack/nova stable/2025.1: Fix case-sensitivity for metadata keys https://review.opendev.org/c/openstack/nova/+/945842 | 05:27 |
| opendevreview | Merged openstack/nova stable/2025.1: Fix disable memballoon device https://review.opendev.org/c/openstack/nova/+/952959 | 05:30 |
| opendevreview | Merged openstack/nova stable/2025.1: Fix case sensitive comparison https://review.opendev.org/c/openstack/nova/+/945843 | 05:30 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Update api-ref for server create https://review.opendev.org/c/openstack/nova/+/937534 | 05:34 |
| opendevreview | Merged openstack/nova stable/2025.1: [doc]Clarify where to set pci_in_placement https://review.opendev.org/c/openstack/nova/+/951624 | 05:35 |
| opendevreview | Merged openstack/nova master: api: Separate volume, snapshot and volume attachments https://review.opendev.org/c/openstack/nova/+/952347 | 05:36 |
| opendevreview | Merged openstack/nova master: tests: Use valid UUIDs for cinder resources https://review.opendev.org/c/openstack/nova/+/952935 | 05:36 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix KeyError on assisted snapshot call https://review.opendev.org/c/openstack/nova/+/900783 | 05:49 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Add upgrade status check for duplicate cell names https://review.opendev.org/c/openstack/nova/+/901810 | 05:59 |
| opendevreview | Merged openstack/nova master: api: Only apply "soft" additionalProperties validation to requests https://review.opendev.org/c/openstack/nova/+/952936 | 06:04 |
| opendevreview | Merged openstack/nova stable/2024.2: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945440 | 06:04 |
| opendevreview | Max proposed openstack/nova master: performance: reduce calls to libvirt / add caching https://review.opendev.org/c/openstack/nova/+/922855 | 06:43 |
| 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 | 07:32 |
| ralonsoh | sean-k-mooney, hello! qq regarding this: https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/sriov-trusted-vfs.html | 07:58 |
| ralonsoh | so if we have a VF bond inside the VM (with trusted VFs), it is possible to change the port MAC. But that will make the SR-IOV agent to fail. When the MAC-PCI address pair doesn't match, it returns a warning and forces a full resync | 07:59 |
| ralonsoh | it will repeat this every cycle (that means, every 2 seconds, by default) | 07:59 |
| ralonsoh | did we considered somehow this scenario?? from the Neutron point of view | 08:00 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: [doc]Clarify where to set pci_in_placement https://review.opendev.org/c/openstack/nova/+/958623 | 08:00 |
| gibi | sean-k-mooney: dansmith: bauzas: we have both green nova-next and unit test results for the nova-conductor eventlet removal change. See my comment in https://review.opendev.org/c/openstack/nova/+/957088/6#message-5d92177333ca556fc30c6934603d37ab55cd161c | 08:27 |
| gibi | sambork: ^^ | 08:27 |
| bauzas | gibi: that's on my today's duties | 08:27 |
| bauzas | I'm finishing up the AMD SEV-ES series | 08:27 |
| gibi | I will do some local manual testing now and report back on the same patch | 08:27 |
| bauzas | ++ | 08:30 |
| gibi | sambork: as far as I see this is the only remaining ask form yesterday https://review.opendev.org/c/openstack/nova/+/957088/6#message-cd81d9ce4afbc379e730f15d8df8334a5303e42f | 08:32 |
| sambork | gibi, ack, thanks | 08:32 |
| gibi | sambork: hm | 08:32 |
| gibi | sambork: wait a sec | 08:32 |
| gibi | sambork: I have a small thing in the parent of that https://review.opendev.org/c/openstack/nova/+/957424 so if we anyhow want to touch the top then I would like to fix the bottom as well in the same run | 08:33 |
| gibi | sambork: I guess it is easier if I just go and do both changes in the same push | 08:34 |
| sambork | gibi, ok thanks a lot! | 08:34 |
| gibi | sambork: also sean-k-mooney is happy that the doc/reno/zuul patch is separate so I will not squash that in https://review.opendev.org/c/openstack/nova/+/958575/1 | 08:34 |
| gibi | bauzas: ^^ hold you reviews until I re-spin | 08:35 |
| bauzas | ack, anyway, I was aiming to review only by the next 30 mins, no worries | 08:36 |
| opendevreview | Merged openstack/nova stable/2024.1: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/945100 | 08:36 |
| bauzas | tkajinam: I finished reviewing your series, nothing holding (I mostly +2d) except one breaking change you introduce by requiring a SEV trait | 08:42 |
| bauzas | I overlooked the spec and nothing was mentioned in the upgrade section, but I do feel that if we start requiring a trait, then we need to mention to the operator that he has to fully upgrade his computes then | 08:43 |
| bauzas | or he wouldn't get old computes supporting SEV too | 08:44 |
| bauzas | that's what I called a behavioural change | 08:44 |
| bauzas | sean-k-mooney[m]: when you're up, I'd like your thoughts on the rolling upgrade scenario with SEV nodes | 08:45 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Ask for pre-prod testing for native threading https://review.opendev.org/c/openstack/nova/+/957424 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-conductor in native threading mode https://review.opendev.org/c/openstack/nova/+/958575 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Allow to start unit test without eventlet https://review.opendev.org/c/openstack/nova/+/953436 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [CI]Make nova-tox-py312-threading voting https://review.opendev.org/c/openstack/nova/+/955791 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Do not yield in threading mode https://review.opendev.org/c/openstack/nova/+/950994 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Make RBD Tpool usage conditional https://review.opendev.org/c/openstack/nova/+/956089 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Make libvirt Tpool proxying conditional https://review.opendev.org/c/openstack/nova/+/956090 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Fix ProviderTree copying with threading Lock https://review.opendev.org/c/openstack/nova/+/956091 | 08:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [test]Further categorization of disabled unit tests https://review.opendev.org/c/openstack/nova/+/956092 | 08:52 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [vncproxy]Handle ssl.wrap_socket removal in py312 https://review.opendev.org/c/openstack/nova/+/955915 | 08:52 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor https://review.opendev.org/c/openstack/nova/+/952666 | 08:52 |
| gibi | bauzas: done. you can go wild now :) | 08:53 |
| * gibi goes back to his local devstack running manual tests on the image cache with threading | 08:53 | |
| bauzas | gibi: ack | 09:03 |
| tkajinam | bauzas, the HW_CPU_X86_AMD_SEV trait is added even in compute nodes. https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L13223 | 09:06 |
| tkajinam | bauzas, the trait hasn't been unused really in scheduling but it has been added to compute nodes with sev enabled. so it does not break scheduling to old compute nodes with SEV | 09:06 |
| bauzas | oh, you're right, and in the reshape, you moved it to the nested RP | 09:06 |
| tkajinam | yes | 09:06 |
| bauzas | my brain forgot that while I was still reviewing it | 09:07 |
| bauzas | sorry | 09:07 |
| tkajinam | no, np | 09:07 |
| bauzas | changing my vote then | 09:07 |
| bauzas | tkajinam: I also have a slight concern, about some deprecation release value you change | 09:07 |
| bauzas | not related to SEV | 09:07 |
| tkajinam | I'll revert that change and push a new version | 09:08 |
| tkajinam | one sec | 09:08 |
| tkajinam | (the others are just rebased so +2 should be kept | 09:08 |
| bauzas | cool | 09:09 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | 09:09 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | 09:09 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | 09:09 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | 09:09 |
| bauzas | and thanks for being present | 09:09 |
| tkajinam | np and thank you for the review ! | 09:10 |
| gibi | sambork: bauzas: sean-k-mooney: dansmith: local testing of the image cache shows that we have a bug somewhere around executor shutdown as only one of the two hosts get the image if the executor size is 1, If I increase the executor size to 2 then both gets it. See logs in https://review.opendev.org/c/openstack/nova/+/957088/7#message-a1b56a536b88c1f4372a2d986364a1f61d5c75af | 09:17 |
| bauzas | hmmm | 09:19 |
| sambork | gibi, ack, checking | 09:19 |
| gibi | If I have to guess then it is a difference in behavior in executor shutdown when there are queued tasks between eventlet and threading executors | 09:20 |
| gibi | but I have to prove that... | 09:20 |
| bauzas | tkajinam: saw my other concern about the nested RP deletion when the config changes ? | 09:24 |
| bauzas | we should mention that in the docs | 09:25 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Purge nested SEV RPs when SEV is disabled https://review.opendev.org/c/openstack/nova/+/958626 | 09:29 |
| tkajinam | bauzas, yes I saw it... and think we can try ^^^ | 09:29 |
| sambork | gibi, it maybe logic is a little bit different and in case of threadPoolExecutor we are not using work_queue in shutdown logic | 09:30 |
| bauzas | I had that approach first when fixing the GPU SRIOV RPs | 09:30 |
| tkajinam | bauzas, I noticed one difference between vGPU RP and SEV RP. The former is named according to definition in nova.conf while the other is named statically so purging SEV rp should be possible | 09:30 |
| bauzas | tkajinam: yes, you're correct | 09:30 |
| bauzas | we statically define the list of RPs based on what the op provided | 09:31 |
| bauzas | while here, we automatically create the RPs based on what libvirt driver detects | 09:31 |
| tkajinam | yeah | 09:32 |
| bauzas | so yeah, we could do what you wrote (reporting total=0 so ensure_rps() will wipe it) | 09:32 |
| bauzas | nice catch | 09:32 |
| tkajinam | one challenge with vGPU is that it loose the name of RP when a record is completely removed from nova.conf | 09:32 |
| tkajinam | I mean nova loose * | 09:32 |
| bauzas | yes, this is config-driven | 09:32 |
| tkajinam | s/loose/lose/ | 09:33 |
| tkajinam | yeah | 09:33 |
| tkajinam | but for sev we know the exact names, as you said | 09:33 |
| bauzas | anyway, I'll quickly review your patch and then I'll see how much I can help gibi and sambork on their eventlet conductor patches | 09:33 |
| tkajinam | (I updated the functional tests to prove it, too | 09:33 |
| bauzas | tkajinam: perfect, thanks | 09:33 |
| gibi | I confirmed it is the executor.sshutdow's behavior that is different https://paste.opendev.org/show/bmZZr707naiWYHMt7qim/ | 09:35 |
| gibi | I feel this is a bug in futurist as python says all pending tasks should finish https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Executor.shutdown | 09:36 |
| gibi | yepp python's own concurrent.future.ThreadPoolExecutor works as expected so this is a futuris bug. I will file it | 09:39 |
| bauzas | gibi: excuse my ignorance but I'm getting hard to find how you found that only one host got the image when comparing paste.opendev.org/show/b1TPrh7ESmcIqWuTZx3D/ and paste.opendev.org/show/bGwpu8My66GcyR8T12sW/ | 09:40 |
| bauzas | I see that compute1 emitted a notification saying it cached the image but I have no clue where the other compute said nooope | 09:41 |
| sambork | ok, so I assume that we are block here (creating some class witch will overwrite shutdown behaviour sounds like to much) | 09:41 |
| gibi | Aug 27 09:07:07 aio nova-conductor[117076]: INFO nova.conductor.manager [None req-8fc723e3-ecc0-4ee3-a4aa-fa33aa2eaf94 admin admin] Preparing to request pre-caching of image(s) 342349b7-351a-470d-92ee-c99f581e55e7 on 2 hosts across 1 cells. | 09:41 |
| bauzas | I mean, I trust you but I want to be able to recognize that in logs | 09:41 |
| gibi | Aug 27 09:07:11 aio nova-conductor[117076]: INFO nova.conductor.manager [None req-8fc723e3-ecc0-4ee3-a4aa-fa33aa2eaf94 admin admin] Image pre-cache operation for image(s) 342349b7-351a-470d-92ee-c99f581e55e7 completed in 4.54 seconds; 1 cached, 0 existing, 0 errors, 0 unsupported, 0 skipped (down) hosts | 09:41 |
| bauzas | oh the "1 cached, gotcha" | 09:42 |
| bauzas | thanks | 09:42 |
| gibi | if you check the same log in the non threading case or in the executor=2 case the you will see the second log showing two cached hosts | 09:42 |
| bauzas | yup, saw it thanks | 09:42 |
| gibi | also the ls command from the two nodes shows that only aio got the image in _base compute1 does not | 09:42 |
| gibi | sambork: yeah I feel the same, I don't think we should try to fix it in one and a half days and even if we have the fix it will be more surgery that I can expect folks will be able to review in short notice | 09:43 |
| gibi | I have to drop for a lunch now sorry... | 09:44 |
| sambork | gibi thanks for testing sorry that I didn't catch it | 09:44 |
| gibi | no worries this is team work :) | 09:46 |
| opendevreview | Merged openstack/nova stable/2024.1: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/945101 | 10:04 |
| opendevreview | Merged openstack/nova stable/2024.1: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/937611 | 10:04 |
| sean-k-mooney | gibi: so i belive if you call shutdwon on an executor pool that has pending task it just discards them | 11:02 |
| sean-k-mooney | gibi: at least i belive that how the tread pools in the std lib concurrent.threadpool and process pool | 11:03 |
| sean-k-mooney | gibi: whil i could not express point to this in doc this is part of the reason i orginallys asked that we do not rely on shutdown for the pool to finish all work. i wanted to keep a list of all the future for the exectuted tasks then wait for them to complete | 11:04 |
| bauzas | sean-k-mooney: the SEV-ES is fully reviewed by me, I think we have a good opportunity to add that in Flamingo | 11:06 |
| sean-k-mooney | bauzas: ok ill take a pass on it soon then | 11:07 |
| sean-k-mooney | just sarting a littel late today, i got new ubiquit netowrking gear and may have bene up till 4 tweaking it.... | 11:07 |
| * sean-k-mooney tasty tasty coffee | 11:08 | |
| gibi | sean-k-mooney: the python stdlib and the greenpool in futurist behaves the same and waits for all pending tasks, the futurist threadpool only waits for the running tasks not the queued ones. I think this is a bug in futurist as it should mimick the stdlib behavior | 11:22 |
| gibi | sean-k-mooney: and yes we agreed that we should refactor the logic to be nicer than shutdown | 11:22 |
| gibi | now we will have plenty of time for it | 11:23 |
| gibi | :) | 11:23 |
| gibi | still I will file a bug to futurist as this is a problem even for others switching from GreenThreadPoolExecutor to ThreadPoolExecutor within futurist | 11:27 |
| sean-k-mooney | gibi: are you goign ot unparent the untit test form the conductor change if we are not proceedign with it | 11:28 |
| gibi | yepp I will | 11:28 |
| sean-k-mooney | ack did you seem my comment about the db transaction issue | 11:28 |
| gibi | conductor will wait for Gazpatcho the unit test can go a bit if we want into F after FF | 11:28 |
| sean-k-mooney | i think im just going to call that the GG release | 11:29 |
| gibi | haven't seen the db comment yet, I will check, I assume it is abotu an unit test issue | 11:29 |
| gibi | sean-k-mooney: hehe GG sounds good :) | 11:29 |
| sean-k-mooney | so there was only one failing test case in the non voting zuul job patch | 11:29 |
| sean-k-mooney | it passed on the next 2 | 11:29 |
| sean-k-mooney | so either that test need to be after the fixture change | 11:30 |
| sean-k-mooney | or its flaky under threading and need more investigation | 11:30 |
| sean-k-mooney | so i was going to suggest adding it to the exclude list | 11:30 |
| sean-k-mooney | i was tired last night so i didnt dign into the error much | 11:30 |
| sean-k-mooney | gibi: i might do this as well but you may want to run it in a loop, im thinking of just letting the voting patch run in a loop executing unit test for an hour or so on my home server | 11:31 |
| sean-k-mooney | actully i will kick that off now | 11:32 |
| gibi | sean-k-mooney: I did run them in a loop locally. But I will investigate your comment | 11:42 |
| sean-k-mooney | it was exactly 1 failng test so it could be just a one off cause by some test to test interaction | 12:00 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Purge nested SEV RPs when SEV is disabled https://review.opendev.org/c/openstack/nova/+/958626 | 12:32 |
| tkajinam | my bad. I though I run the whole functional tests but I didn't (and didn't caught some tests also needing update ) | 12:39 |
| tkajinam | I thought * | 12:39 |
| ralonsoh | sean-k-mooney, hello! maybe you missed my message about SR-IOV trusted VFs and MAC changing (https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/sriov-trusted-vfs.html) | 12:53 |
| sean-k-mooney | ralonsoh: ya i didnt see it but i think we talked about it in the past | 12:56 |
| sean-k-mooney | trusted vf shoudl not allow the mac to be changed form the guest | 12:56 |
| sean-k-mooney | i think we talked about there beign a bug in one of the intel drivers? | 12:56 |
| sean-k-mooney | the tursted vf spec allow the VF to be in promisous mode | 12:57 |
| sean-k-mooney | so it can recive traffic that is not destented for its mack | 12:57 |
| sean-k-mooney | but its mac shoudl be still enforced by nova/neutron to be the neutron port mac | 12:57 |
| sean-k-mooney | the kernel dirver is free to rest the mack to all 0000 when the vm is stopped but if it is started again it shoudl be programed by nova/libvirt to the requsted mac again | 12:59 |
| sean-k-mooney | changes to things like link state in the guest or phsysical on the host shoudl not impact the mac at all | 12:59 |
| sean-k-mooney | chanign the mac in the guest shoudl not propagate to the vf in trusted mode and if it does i woudl consider that to be a security issue | 13:00 |
| sean-k-mooney | specificly in the vendors PF and VF driver | 13:00 |
| ralonsoh | sean-k-mooney, but port bonding (and MAC changing) is also considered in the nova spec | 13:01 |
| sean-k-mooney | yes an no | 13:01 |
| sean-k-mooney | what we were descibeing there | 13:01 |
| sean-k-mooney | was the ablity to create a bond port in the guest with a diffent mac then what is on the VF | 13:02 |
| sean-k-mooney | on the host | 13:02 |
| sean-k-mooney | how this used to work is if you change the mac on the guest interface the host mac woudl remain the same | 13:02 |
| sean-k-mooney | in ip tools | 13:02 |
| sean-k-mooney | or ifconfig | 13:02 |
| sean-k-mooney | btu the mac on the packet that was sent on the wire would be updated | 13:03 |
| ralonsoh | sean-k-mooney, ahhhh I thought that if you add two interfaces to a bond (inside the VM) you also change the VF MAC | 13:03 |
| sean-k-mooney | ralonsoh: i think that is what has changed | 13:03 |
| sean-k-mooney | you can change the guest visable side | 13:03 |
| ralonsoh | ahhhh so you can update the bond MAC but it will eventually use the VF MAC outside the VM | 13:04 |
| ralonsoh | I didn't know that | 13:04 |
| sean-k-mooney | btu on niantic for exampel that never actully changed the mac on the host side form the perspecitive of libvirt or ifconfig | 13:04 |
| sean-k-mooney | it would change the mac on the wire which wi why it worked btu the comtople plane view was nto updated | 13:04 |
| sean-k-mooney | i woudl assume at some point they hooked up the mailbox protocol to propagate the mac change | 13:04 |
| ralonsoh | yeah, this is what is happening now | 13:05 |
| sean-k-mooney | ralonsoh: ideaaly the sriov nic agent would use the pci adddress not the the mac/name | 13:05 |
| ralonsoh | and this is of course an issue (at least from Neutron point of view) | 13:05 |
| ralonsoh | sriov agent uses the MAC/PCI tuple to identify a port | 13:05 |
| sean-k-mooney | is this the cause of the customer bug where tehy were seeing the state flap | 13:06 |
| ralonsoh | yes | 13:06 |
| sean-k-mooney | ah ok. im glad i updated that to the netwrokign team so :P | 13:06 |
| sean-k-mooney | so ya i woudl consider just using the pci adress | 13:06 |
| sean-k-mooney | the reason you check both is because of connectx-3 | 13:07 |
| ralonsoh | so that would require a refactor of the sriov agent | 13:07 |
| sean-k-mooney | in that generation of nic and only in that nic | 13:07 |
| sean-k-mooney | you could have 2 pfs with the same pci adress | 13:07 |
| sean-k-mooney | it was dumb and broke a bunch of other things and no one does that anymore | 13:07 |
| ralonsoh | that's another story... | 13:08 |
| ralonsoh | but of course, that won't work with ML2/SRIOV | 13:08 |
| sean-k-mooney | ralonsoh: well just using the pci address shoudl work for ml2/sriov in general | 13:15 |
| ralonsoh | sean-k-mooney, maybe, I need to check that. We need, at least, to write a warning if the expected MAC address is not set | 13:16 |
| ralonsoh | how do I know a VF is used if I the MAC is the only thing I can check (for a PCI address) | 13:16 |
| sean-k-mooney | you know its used by checkign the binding profile in the port | 13:16 |
| sean-k-mooney | we pass the pci_slot | 13:17 |
| sean-k-mooney | var which has the full pci adress | 13:17 |
| ralonsoh | yes but I mean, in the SR-IOV agent we are detecting the port binding checking that the VF in a specific PCI has the expected MAC | 13:18 |
| ralonsoh | and the MAC is set by nova compute | 13:18 |
| sean-k-mooney | ya so it never actully needed to do that for what it worth | 13:18 |
| ralonsoh | that was the trigger to send the vif-plugged event | 13:18 |
| sean-k-mooney | orginally the sriov nic againe was entirly optional and not needed for intel nics | 13:18 |
| sean-k-mooney | it was created by melanonx ot all managing things like link state via the admin state of the port | 13:19 |
| sean-k-mooney | the mac programming to this day is done by nova | 13:19 |
| ralonsoh | or qos or changing the propagation flag | 13:19 |
| ralonsoh | I'll raise this issue in the Neutron community, I'll create a LP bug | 13:20 |
| sean-k-mooney | as with everythign else the l2 part of the networing (seting the mac) is done by nova based on the mac set in the neutron port | 13:20 |
| sean-k-mooney | ack | 13:20 |
| sean-k-mooney | i think its fair to raise a warnign if it not the expectev version and its not using trusted VF | 13:20 |
| sean-k-mooney | if it is then it shoud be info level IMO | 13:20 |
| sean-k-mooney | maybe warning is valid but this is apprently vendor and drive rdependnet beahivor | 13:21 |
| sean-k-mooney | warnings are normmly a call to arms for an operator to fix somethign and i dont think there is anything for them to fix in this case | 13:22 |
| ralonsoh | warning is better than forcing the resync | 13:22 |
| sean-k-mooney | oh im not saying we shoudl resync | 13:22 |
| ralonsoh | well, if the mac is changed and doesn't match with the Neutron port one, this is indeed a warning | 13:23 |
| sean-k-mooney | im just sayign the log message shoudl maybe be at a lower level | 13:23 |
| sean-k-mooney | ack | 13:23 |
| ralonsoh | I'll raise the bug and propose a patch, we can decide this in the review | 13:23 |
| sean-k-mooney | you could also cosnider deprecating trusted_vf.... | 13:23 |
| ralonsoh | for sure, that should only happen with trusted VF | 13:24 |
| ralonsoh | if the port is not trusted, this is for sure something more serious | 13:24 |
| sean-k-mooney | i dont like that feature becasue we stilll have not fixed the fact it required you to write data to a field only nova shoudl modify | 13:24 |
| sean-k-mooney | i.e. there shoudl be a seprate trunsted vF extention that does not require you to mess with the binding profile | 13:25 |
| sean-k-mooney | since humans shoudl never write to that | 13:25 |
| ralonsoh | sorry, I don't get your point here | 13:25 |
| ralonsoh | Neutron does not set the VF trusted flag | 13:26 |
| sean-k-mooney | the trusted VF feature required you to requet it by writign data to the binding:profile field | 13:26 |
| ralonsoh | ahhh ok ok | 13:26 |
| ralonsoh | now I understand | 13:26 |
| sean-k-mooney | correct neutron does not a human has to inject data into a filed that only nova should modify | 13:26 |
| ralonsoh | well, we have done this before (removing things from the binding profile) | 13:26 |
| sean-k-mooney | there shoudl be a port extenion for it instead | 13:27 |
| sean-k-mooney | yep | 13:27 |
| ralonsoh | agree | 13:27 |
| ralonsoh | ok, I'll open another LP bug heheheheh | 13:27 |
| sean-k-mooney | it woudl be nice to finally fix this so we dont need custom policy for the binding:profile filed | 13:27 |
| sean-k-mooney | thanks | 13:27 |
| gibi | I'm cancelling the eventlet sync today for the sake of the FeatureFreeze. I'm not tracking anything that is critical for the FF from the eventlet-removal series. The nova-conductor change is blocked by a bug in futurist so that is moved to GG. | 13:55 |
| dansmith | gibi: I'm just reading that now | 13:56 |
| dansmith | futurist aside, we could just make a list of threads and wait for them manually right? | 13:56 |
| gibi | dansmith: right | 13:56 |
| dansmith | probably best to move to G anyway given it's not critical | 13:56 |
| gibi | we have a list of futures we can wait on | 13:56 |
| dansmith | ack | 13:56 |
| gibi | I will file a futurist bug as it might effect us or others elswhere when we shutting down executors | 13:57 |
| gibi | but that is also post FF :) | 13:57 |
| * dansmith nods | 13:57 | |
| sambork_ | gibi, ack, I will work on that after ff then | 13:57 |
| *** sambork_ is now known as sambork | 13:58 | |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814 | 13:58 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | 13:58 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | 13:58 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | 13:58 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | 13:58 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Purge nested SEV RPs when SEV is disabled https://review.opendev.org/c/openstack/nova/+/958626 | 13:58 |
| ralonsoh | sean-k-mooney, just a heads-up: https://review.opendev.org/c/openstack/neutron/+/926068 | 14:00 |
| ralonsoh | we are already sending the "trusted" field in the port dict | 14:00 |
| ralonsoh | I think we don't set it always (if the flag is not present). But if the flag is True or False, we send this new field since 2024.2 | 14:01 |
| dansmith | gmaan: are you rebasing this for FF? https://review.opendev.org/c/openstack/nova/+/957578 | 14:09 |
| sean-k-mooney | ralonsoh: oh nice | 14:24 |
| sean-k-mooney | ralonsoh: so if we have not picked that up yes on nova we shoudl supprot it | 14:24 |
| sean-k-mooney | ralonsoh: so ya looks like there are no nova patches to finish it | 14:25 |
| dansmith | you know, I'm just realizing that we never merged this repro/fix for placement: https://review.opendev.org/c/openstack/placement/+/945464 | 14:25 |
| sean-k-mooney | ralonsoh: so am i correct that htis can now be set on a port without modifying the binding:profile at all | 14:25 |
| dansmith | gibi: ^ | 14:26 |
| sean-k-mooney | dansmith: ya i have that open in a tab form last week | 14:26 |
| sean-k-mooney | dansmith: i assume you would like to get that in this cycle | 14:26 |
| gibi | dansmith: I can take a look quickly now | 14:26 |
| sean-k-mooney | i can try and make time to review it too | 14:27 |
| gibi | unfortunately I missed it completly | 14:27 |
| dansmith | I wish it was already because the context is out of my head now.. but yes, would very much like to have it merged | 14:27 |
| sean-k-mooney | looks like you adressed my main comments. i just discarded one i had pienidng because its not worth changign the patch for | 14:28 |
| sean-k-mooney | dansmith: the answer to https://review.opendev.org/c/openstack/placement/+/945464/comment/0189c002_387845d8/ was just the test is doing to diffent things so i woudl have made it two tests | 14:29 |
| sean-k-mooney | ill just ack tthat comment and we can leave it as is | 14:29 |
| sean-k-mooney | the repoducer looks fine ill need to spen a littel more time on the actual fix but ill do that later today | 14:32 |
| ralonsoh | sean-k-mooney, yes, you can rely on this flag instead of the port binding | 14:32 |
| ralonsoh | we are setting now in both places (the field and port binding) | 14:32 |
| ralonsoh | we'll remove the last one (port binding) once accepted in Nova | 14:32 |
| sean-k-mooney | ack. ill add nova ot the bug and check with other if we are ok to fix and backport that as a security hardening bug | 14:33 |
| sean-k-mooney | if not then ill propose doing it as a specless blueprint next cycle | 14:33 |
| dansmith | gibi: I was going to ping our PTL, but ... https://review.opendev.org/c/openstack/nova/+/957424 | 14:42 |
| gibi | dansmith: I'm +2 on both patch in placement about the overallocation. Thanks both was pretty clear. | 14:43 |
| dansmith | I wonder if we should point them to a specific outlet (or outlets) to report success | 14:43 |
| dansmith | gibi: sweet thanks | 14:43 |
| gibi | dansmith: I can ask them to drop a mail to the ML or show up on IRC. | 14:44 |
| gibi | probably ML is easier for them | 14:44 |
| dansmith | yeah the former is what I was thinking.. I know some may not even go that far, so I wish we had another venue but.. at least asking for success reporting seems like a good idea | 14:44 |
| gibi | I will respin and add it | 14:45 |
| gibi | (and in the same time I will remove the nova-conductor from the series) | 14:45 |
| dansmith | maybe put bauzas' personal email and cell number (as our closest TC rep) in there if they don't want to join the ML :D | 14:45 |
| gibi | lol :) | 14:45 |
| bauzas | hmmm, WAT ? | 14:45 |
| dansmith | gibi: also why not just squash those renos into one? | 14:45 |
| bauzas | $context ? | 14:45 |
| gibi | dansmith: about the renos there. We already have two from two independent patch but yeah I can try to merge them in that commit and see what our doc gen says about a deleted reno | 14:46 |
| dansmith | not a big deal but when I read the second one I thought it was accidental duplication until I flipped back and forth a couple times to see | 14:46 |
| dansmith | gibi: oh right, duh, okay nevermind then | 14:46 |
| dansmith | usually renos in patches are new and I was reading it as if you were adding those.. no need to fix now I think | 14:47 |
| gibi | OK | 14:47 |
| gibi | Uggla: ping :) | 15:01 |
| Uggla | gibi pong ! :) | 15:02 |
| gibi | probably a netspilt happened between the IRC servers but those should be reported to us. At least in the univesity days that was somewhat frequent and that was a way to steal nicks :) | 15:02 |
| bauzas | gibi: dansmith: what was the problem with reno ? sorry, hardly following | 15:11 |
| dansmith | yeah I think after some netsplit my nick list just didn't recover.. I restarted my client and it's back now | 15:12 |
| dansmith | bauzas: no problem | 15:12 |
| bauzas | also, I'd appreciate if some cores could give a look at tkajinam's series on SEV ES | 15:12 |
| bauzas | I reviewed that, Uggla found some typos that tkajinam will update but apart from that, we're in a very good spot to support next generation of AMD SEV :) | 15:12 |
| dansmith | bauzas: as I said, I'm not reviewing that before tomorrow.. I'm totally blank on it and don't think I'd be doing a good job in such a short time frame... just FYI | 15:12 |
| bauzas | dansmith: well, it was a general reminder to all of us, not particularly you who already said that indeed, cool | 15:13 |
| dansmith | yep, I know, just sayin' :) | 15:13 |
| bauzas | there is also a quite simple feature patch worth reviewing, which is to copy our provider.yaml, I started reviewing it and I have an open question : https://review.opendev.org/c/openstack/nova/+/948304 | 15:14 |
| bauzas | we could fix that in a FUP if other cores like it | 15:14 |
| gmaan | dansmith: RE 957578: ah it merge conflict, I will rebase it. it was all good until last night. testing and everything done for this and it is good to review (once i rebase) | 15:15 |
| dansmith | ack | 15:15 |
| bauzas | gmaan: I can give it a shot | 15:16 |
| bauzas | fwiw, the etherpad is updated with my findings https://etherpad.opendev.org/p/nova-2025.2-status | 15:16 |
| bauzas | people can use it for directing reviews | 15:16 |
| lajoskatona | bauzas, Uggla: Hi, perhaps you can help me out, we have a bug originally from a downstream customer: https://bugs.launchpad.net/nova/+bug/2051685 for migration | 15:29 |
| lajoskatona | bauzas, Uggla: it hit us few cycles back and than rubasov made an upstream reproduction which you can read in the bug description but he hit some walls in understanding the depths of Nova as you can read at the end of the report :-) | 15:30 |
| lajoskatona | bauzas, Uggla: if we should have a pointer if the issue is really an issue and can be fixed would be enough help to keep working on it but we lost how to dig deeper and if it is really something that can be / worth to be fixed | 15:31 |
| Uggla | lajoskatona, at least I can add this bug for review in our next bug scrubbing. | 15:33 |
| lajoskatona | Uggla: Thanks for your time, if any more info is needed we can check and add o course to the LP | 15:34 |
| Uggla | lajoskatona, I'll try to discuss it in next nova meeting. But I can't promise we will have time, depending of the agenda. | 15:35 |
| lajoskatona | Uggla: no problem, thanks | 15:36 |
| sean-k-mooney | lajoskatona: so use reset state after a migration error si never corect | 16:15 |
| sean-k-mooney | so if this only happens when you do that its not really a valid bug | 16:15 |
| sean-k-mooney | lajoskatona: also im surpesed we accepted --availability-zone :devstack0 | 16:16 |
| sean-k-mooney | in new micorversion you ment to pass --host | 16:17 |
| sean-k-mooney | if you jsut want to slect a host | 16:17 |
| sean-k-mooney | i tought the az was intended to be requried and just passing :<host> was not intended to be supprot but perhaps that worked by acidnet | 16:18 |
| lajoskatona | sean-k-mooney: reset state was only used to show that in devstack the issue can happen, as it happened in some customer site without proper logs and reproduction | 16:18 |
| sean-k-mooney | we never really encurraged that usage | 16:18 |
| sean-k-mooney | right but reset state will break novas ablity ot properly clean up | 16:18 |
| sean-k-mooney | as will restarting the nova-comapute durign the mighration | 16:19 |
| lajoskatona | the issue is that when something happens with the destination host during migration the migration can stuck in error case | 16:20 |
| sean-k-mooney | well yo say stuck in error but i tough erro was a valid end state | 16:20 |
| sean-k-mooney | so its not stuck its in the terminal state | 16:21 |
| sean-k-mooney | or one of the terminal states | 16:21 |
| lajoskatona | as rubasov added to the last lines as a thought experiment: "I don't see it yet, how this should be fixed. Maybe a migration should never be stuck indefinitely in status=error...." | 16:21 |
| sean-k-mooney | failed models a diffent endsate then error | 16:21 |
| sean-k-mooney | error is something went wrong that we cant recover form gracefully liek the dest host gets restarted | 16:22 |
| lajoskatona | yes of course | 16:22 |
| sean-k-mooney | failed is the end state when it somethig we can properly recover form | 16:22 |
| sean-k-mooney | like we try to migrate and the cpu is incompatible | 16:22 |
| sean-k-mooney | so the migration status being in error for ever is nto a bug to me | 16:23 |
| sean-k-mooney | the orignal issue was caused by "overcommit on dedicated PCPUs and CPUPinningInvalid exception" | 16:23 |
| sean-k-mooney | I.E. there was already invlaid sate in one or boht of the compute nodes | 16:24 |
| lajoskatona | and the update_available_resource periodically fetches these also and tries to apply the migration that ended in error state but the repeated migration for the same server to the same host succeded so it should be find by the method that the migration is really done by a new migration (server uuid - dest host pair) | 16:24 |
| sean-k-mooney | i.e. vms not runningn on the right core or the oepration modfied the nova config to change the core set | 16:24 |
| lajoskatona | so the question is if we can say that ahhh, the same VM to the same host migration operation is finished so we can forget to stress on the previous migration (same vm uuid same host) that failed ? | 16:26 |
| sean-k-mooney | in general no | 16:28 |
| lajoskatona | so it is really a corner case as I see not error due to the things you mentioned (pcpu config or such) but like issue with the compute itself and after the fix the migration can be repeated | 16:28 |
| sean-k-mooney | but we liekly do have a bug in the logic | 16:28 |
| sean-k-mooney | i dont thnk it woudl be correct for the erroed migration to be updated to failed | 16:29 |
| sean-k-mooney | is shoudl stay in error | 16:29 |
| sean-k-mooney | but if the vm is not on this host we shoudl not process the old migration on new iterations | 16:29 |
| sean-k-mooney | of the update_aviable_resouces perodic | 16:29 |
| sean-k-mooney | movign it to fialed might achive that | 16:29 |
| lajoskatona | that's fair to rethink it and make it clear and we can document it for customers in such case in worst case | 16:29 |
| sean-k-mooney | but im not sure we can alwasy assume that is safe to do | 16:30 |
| lajoskatona | sounds great to think at least about it | 16:30 |
| sean-k-mooney | you were testing bfv was it using ceph by the way? | 16:31 |
| sean-k-mooney | if so the already exist erro might eb related to https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.ensure_libvirt_rbd_instance_dir_cleanup | 16:31 |
| lajoskatona | to tell the truth I am not sure but would say no (have to double check) | 16:31 |
| sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1414895 | 16:32 |
| sean-k-mooney | is one of the rrefenece bugs | 16:32 |
| sean-k-mooney | we dont generally delete the instnace storage on the dest on start up because we dont want ot loose data | 16:33 |
| sean-k-mooney | i.e. incase the live migration actuly commpelted at teh libvirt level while the agent was being restarted | 16:34 |
| lajoskatona | thanks I check this issue also if can be related | 16:34 |
| sean-k-mooney | when an migration ends in error it means an operator might need to fix the db | 16:34 |
| sean-k-mooney | to update the host to bring nova back in sync with where the vm is. or carfully move the vm back ot the souce host | 16:35 |
| sean-k-mooney | if a migration end in failed there shoudl be no action needed by an operator to fix anything | 16:35 |
| opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | 16:55 |
| gmaan | bauzas: thanks, rebased it ^^ dansmith sean-k-mooney ^^ | 16:56 |
| dansmith | ack | 16:56 |
| bauzas | gmaan: I'm a bit out of steam now, I'll look at it tomorrow morning | 16:57 |
| gmaan | no issue. | 16:57 |
| sean-k-mooney | gmaan: i did a test in cidner to see if i coudl make it work with the glance revert | 16:59 |
| sean-k-mooney | but id dint work and i dont know why | 16:59 |
| gmaan | sean-k-mooney: you mean nova change did not work with glance revert? | 17:00 |
| gmaan | or glance revert things only | 17:00 |
| sean-k-mooney | no the cider oen i crfeated | 17:00 |
| sean-k-mooney | i looke at how nova creates our glance client nad tried to do the same in cidner | 17:00 |
| gmaan | ohk, i can check that. cinder to send right roles in nova, I can check for glance | 17:00 |
| gmaan | i checked all those files recently so it will be quick, looking.. | 17:01 |
| sean-k-mooney | https://review.opendev.org/c/openstack/cinder/+/958582 | 17:02 |
| gmaan | sean-k-mooney: here is issue, cinder does not send the confiugured service user to glance instead send the user token (context) + service token so user token does not have 'service' role - https://github.com/openstack/cinder/blob/89709ef589b74506885c72e42cad57eb8dedfb56/cinder/image/glance.py#L134C45-L134C52 | 17:02 |
| gmaan | here cinder should have first try to get the configured service user and that auth plugin (load from keystoneauth) they can send along with service token | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Ask for pre-prod testing for native threading https://review.opendev.org/c/openstack/nova/+/957424 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Allow to start unit test without eventlet https://review.opendev.org/c/openstack/nova/+/953436 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [CI]Make nova-tox-py312-threading voting https://review.opendev.org/c/openstack/nova/+/955791 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Do not yield in threading mode https://review.opendev.org/c/openstack/nova/+/950994 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Make RBD Tpool usage conditional https://review.opendev.org/c/openstack/nova/+/956089 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Make libvirt Tpool proxying conditional https://review.opendev.org/c/openstack/nova/+/956090 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Fix ProviderTree copying with threading Lock https://review.opendev.org/c/openstack/nova/+/956091 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [test]Further categorization of disabled unit tests https://review.opendev.org/c/openstack/nova/+/956092 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [vncproxy]Handle ssl.wrap_socket removal in py312 https://review.opendev.org/c/openstack/nova/+/955915 | 17:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor https://review.opendev.org/c/openstack/nova/+/952666 | 17:03 |
| sean-k-mooney | gmaan that what i was tryign to do here https://review.opendev.org/c/openstack/cinder/+/958582/1/cinder/image/glance.py#145 | 17:04 |
| sean-k-mooney | let me update that quickly to get rid of the pep8 errors so its readable | 17:04 |
| gmaan | sean-k-mooney: but you need to load service user token from keystoneauth and pass it to https://review.opendev.org/c/openstack/cinder/+/958582/1/cinder/image/glance.py#148 | 17:05 |
| gibi | dansmith: fixed the doc pre-prod testing doc patch to ask for a mail. | 17:05 |
| dansmith | gibi: already approved | 17:06 |
| dansmith | thanks | 17:06 |
| gibi | dansmith: thanks! | 17:06 |
| gibi | sean-k-mooney: you threading unit test finding was valid, I missed that in our exclude list in the first patch and only added later. Now it is excluded from the begining | 17:06 |
| gmaan | sean-k-mooney: otherwise auth going to keystone sessions is still user token (with no service role) + service token - https://review.opendev.org/c/openstack/cinder/+/958582/1/cinder/image/glance.py#154 | 17:06 |
| sean-k-mooney | gmaan: that what i was tryign to do by having the session object constucted form teh config | 17:07 |
| sean-k-mooney | im obvioulsy missing a step but im tring to use the user token form the config not the actual user | 17:08 |
| gmaan | I think keystonemiddleware do fetch the headers from auth plugin and populate the context with those data but let me check | 17:09 |
| opendevreview | melanie witt proposed openstack/nova stable/2025.1: libvirt: Get info with abs path, rebase with rel path https://review.opendev.org/c/openstack/nova/+/958674 | 17:10 |
| gmaan | sean-k-mooney: but yes if you can cleanup those pep8, i can read it more clearly | 17:10 |
| sean-k-mooney | im doing that as we speak | 17:10 |
| sean-k-mooney | gibi: ack cool i was hoping it was just that | 17:10 |
| sean-k-mooney | gibi: so its still exclude and or passing in the later patches ya? | 17:11 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | 17:12 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-conductor in native threading mode https://review.opendev.org/c/openstack/nova/+/958575 | 17:12 |
| gibi | sean-k-mooney: yepp it was excluded later, but now it is excluded from the first patch :) thanks for catching it | 17:12 |
| gibi | the conductor series is now move top of master out from the unit test series | 17:13 |
| sean-k-mooney | ack ill loop back over that shortly | 17:13 |
| gibi | thanks. I'm filing the futurist bug now and the end my day | 17:13 |
| sean-k-mooney | i need to actully finish at leat the first patch in the sev series | 17:13 |
| sean-k-mooney | im going to be aroudn for amybe another hour doign review possible a little more | 17:14 |
| sean-k-mooney | gmaan: i didnt have a chance to revew the dnms but did you get clean runs on the service role the last time | 17:14 |
| gmaan | sean-k-mooney: yes, all good. stable job on tempest change was failing in experimental pipeline so I fixed tests to continue using admin on stable and service on master | 17:15 |
| sean-k-mooney | i was mostly happy with your nova change last time i looked so i think we can likely land that today or tomorrow | 17:15 |
| sean-k-mooney | did you see my quetion on the tempest change | 17:16 |
| gmaan | I fixed your doc/release notes comment too | 17:16 |
| gmaan | oh, not yet, checking | 17:16 |
| sean-k-mooney | baout wither the primary role could be service? | 17:16 |
| sean-k-mooney | instead of admin | 17:16 |
| gmaan | sean-k-mooney: oh, that one i replied yes | 17:16 |
| sean-k-mooney | https://review.opendev.org/c/openstack/cinder/+/958582 now passes pep8 | 17:17 |
| gmaan | its not admin. actually 'credential' var in tests is little weird and unreadable | 17:17 |
| gmaan | credentials = ['primary', 'admin', ['service_user', 'admin', 'service']] means: it create three users - 1. user with member role (primary), 2. user with admin (admin), 3. user with admin and saervice role (service_user) | 17:18 |
| gibi | here is the futurist bug https://bugs.launchpad.net/futurist/+bug/2121545 | 17:18 |
| sean-k-mooney | this was a case of "i dont understand how to read that list" so i was just asking why primary was admin for what its worth | 17:18 |
| sean-k-mooney | oh | 17:19 |
| sean-k-mooney | thats how you read it | 17:19 |
| sean-k-mooney | gmaan: ok that not what i was expectign at all ok | 17:19 |
| gmaan | yeah, it take, normal predefined users (primary, admin, reader, alt_admin etc), users with coustom name and roles so it is not so easy to read. | 17:19 |
| gmaan | and with historic alias in tempest, primary == member etc make it more unreadable | 17:20 |
| gmaan | I think we need to get rid of primary and use member consistently | 17:20 |
| sean-k-mooney | ya a dict of username to list of roels would be simpler also | 17:20 |
| sean-k-mooney | ya the indirection though primary also was not somethign i was aware of | 17:21 |
| gmaan | it keep becoming complex with more personas and we need to keep old predefined personas for compatibility | 17:21 |
| sean-k-mooney | i assme that was to deall with "member" vs "_member_" | 17:21 |
| gmaan | self.os is another name of promary/member but we do not use that in many tests :) | 17:22 |
| gmaan | but I have that cleanup in my list | 17:22 |
| gmaan | at least use latest personas name in tests and keep old one just for compatibility if tempest plugin are using | 17:23 |
| sean-k-mooney | ya that woudl help | 17:23 |
| sean-k-mooney | so i need to finsh the sev revew but yuou thin the issue is https://review.opendev.org/c/openstack/cinder/+/958582/2/cinder/image/glance.py#148 | 17:24 |
| sean-k-mooney | evne though i am creating the session form the config now its still not useing tha tfor the user toekn an pulling that form the context | 17:24 |
| sean-k-mooney | nova does https://github.com/openstack/nova/blob/master/nova/service_auth.py#L33-L55 cidner does almost the same https://github.com/openstack/cinder/blob/master/cinder/service_auth.py#L80-L91 | 17:27 |
| gmaan | sean-k-mooney: you are creating the sessions from conf but passing the auth plugin to keystonauth https://review.opendev.org/c/openstack/cinder/+/958582/2/cinder/image/glance.py#145 | 17:27 |
| sean-k-mooney | if you have na idea of how to properly udpat that patch or can comment i can respien it later | 17:28 |
| sean-k-mooney | but i see i can pass auth as a second parmater | 17:28 |
| sean-k-mooney | so i just need to find an incanation to copy past for that | 17:28 |
| gmaan | sean-k-mooney: that is all ok but in that method nova pass the loaded conf service user and cinder just context so user aith plugin loaded from user context | 17:28 |
| gmaan | yes | 17:28 |
| gmaan | for nova case this is here cinder load the internal service user from conf https://github.com/openstack/cinder/blob/master/cinder/compute/nova.py#L98-L100 | 17:29 |
| gmaan | and wrap that with service token in get_auth_plugin | 17:29 |
| gmaan | and then keystonmiddlware gets the right user_token and service_token headres and populate the requext context which is passed to services | 17:30 |
| sean-k-mooney | oh so i need basiclly all of this right https://github.com/openstack/cinder/blob/master/cinder/compute/nova.py#L98-L118 | 17:31 |
| gmaan | yes, you can do all. so like cinder call nova based on what they call they can with pass privileged_user to true or not | 17:32 |
| sean-k-mooney | and ideally cinder would have a glance section like the nova one but i could steal the nova option or the keystone_auth ones just to who it works | 17:32 |
| sean-k-mooney | what im trying to show is that with a change to how cidner calls glance the revert is valid to show that its a cidner bug now a glance one | 17:33 |
| gmaan | sean-k-mooney: that can be wrong but that is why I am checking in cinder code if they register the keystoneauth options for glance section also like they do for nova | 17:33 |
| sean-k-mooney | if i can demonstrate tha then we coudl fix it properly | 17:33 |
| sean-k-mooney | gmaan: no not that i can see form there config ref | 17:33 |
| gmaan | sean-k-mooney: I checked what all method cinder should pass user token (like they do currently) and I think these are the two call cinder need to pass config service user to glance - https://github.com/openstack/cinder/blob/master/cinder/image/glance.py#L345-L370 | 17:36 |
| gmaan | so they can pass privileged_user =True in common mehtod you mentioned to copy from nova file to glance | 17:37 |
| gmaan | those are two glance call have service role for their policy chgeck https://github.com/search?q=repo%3Aopenstack%2Fglance+base.SERVICE&type=code | 17:38 |
| gmaan | rest all other call can continue using the user token. for example, this is nova case where cinder get servers volume from nova and just call it with user token (not configured service user) + service token https://github.com/openstack/cinder/blob/master/cinder/compute/nova.py#L243-L246 | 17:39 |
| sean-k-mooney | ok i was hopign thiw woudl take me a few second to poc | 17:39 |
| sean-k-mooney | but it will take me more time then i have | 17:40 |
| sean-k-mooney | gmaan: is this somethign you could try? | 17:40 |
| sean-k-mooney | gmaan: my concern is releaseing with the glance policy change | 17:40 |
| gmaan | sure, let me update it | 17:40 |
| sean-k-mooney | thanks | 17:41 |
| gmaan | is glance policy changed in this cycle or they are released last cycle? | 17:41 |
| sean-k-mooney | the one in this cycle that was doen last week | 17:41 |
| sean-k-mooney | the thing this reverts https://review.opendev.org/c/openstack/glance/+/958567 | 17:42 |
| gmaan | because that can create issue (leak/security etc) where user with no privilege to get/add location can do it via cinder | 17:42 |
| gmaan | ohk, cook | 17:42 |
| gmaan | cool | 17:42 |
| gmaan | let me update your cinder change | 17:42 |
| gmaan | sean-k-mooney: it is more work then that, cinder does not have service user configuration for glance so we need to 1. add those new conf in cinder 2. set those in devstack () and document it for operator to do the same) 3. load and pass that configured user to glance serviec APIs call | 17:57 |
| gmaan | I can push the changes but I am not sure all these can make it before FF | 17:57 |
| gmaan | whoami-rajat_: ^^ just CC you as you are involved in the service role stuff | 17:58 |
| gmaan | anyways we should do this discussion in glance or cinder channel and can decide what best can be done before FF | 17:59 |
| whoami-rajat_ | i just want to mention that currently cinder passes service_roles:service and not role:service so please modify the policies accordingly to support both scenarios (role:service OR service_roles:service) until we reach a consensus on the right way to do it | 17:59 |
| whoami-rajat_ | I'm trying to get in my patch to adopt GET location API which relies on the above ^ | 18:00 |
| gmaan | sean-k-mooney: and that is released in 2025.1 https://github.com/openstack/glance/blob/stable/2025.1/glance/policies/base.py#L116 | 18:01 |
| sean-k-mooney | whoami-rajat_: so service_roles: service is refering to roles on teh service token | 18:02 |
| sean-k-mooney | which is not somehtign that glance or nova shoudl be checkign in this context | 18:03 |
| gmaan | whoami-rajat_: there is one issue in that. any user who is not allowed to get/add image location and can call cinder API will be able to get/add image location because service_role: will always be successful rule in glance | 18:03 |
| gmaan | whoami-rajat_: I try to add all use case here (5th reply from last ) https://review.opendev.org/c/openstack/nova/+/957578/comment/a097d558_fee01375/ | 18:03 |
| whoami-rajat_ | it shouldn't be if we haven't configured the [service_user] send_service_user_token = True | 18:04 |
| sean-k-mooney | that shoudl more or less always be true | 18:04 |
| gmaan | sean-k-mooney: yes | 18:04 |
| gmaan | whoami-rajat_: operator need to do that which is for other purpose than RBAC. user token expiry use case | 18:05 |
| sean-k-mooney | ^ that | 18:05 |
| gmaan | both are for service to service communication but for separate purpose. that is what I was also confused with and was doing it in nova until sean-k-mooney corrected me | 18:06 |
| whoami-rajat_ | I understand, just my main focus is not to break existing functionality, glance and cinder (and even nova) has been interacting in this way so we should keep the behavior when implementing the new one | 18:06 |
| gmaan | sean-k-mooney: so 2024.2 policy was correct, I am wondering how it was working in cinder and your revert which is logically same as this is failing? https://github.com/openstack/glance/blob/stable/2024.2/glance/policies/base.py#L114 | 18:07 |
| whoami-rajat_ | and TBH, i really don't like the redundancy as highlighted here https://review.opendev.org/c/openstack/glance/+/958567/comments/37c4390c_90f23c9d | 18:07 |
| sean-k-mooney | whoami-rajat_: the current glance bevharie as fo 7 days ago or wheneve ris portiotaly a security problem | 18:07 |
| sean-k-mooney | its using the service token for something ti was not intended to be used for | 18:07 |
| sean-k-mooney | we did a one off exccption for the cinder cve | 18:07 |
| sean-k-mooney | btut that is not a policy check via the polciy framwork | 18:08 |
| sean-k-mooney | that a special case that woudl eventually go away | 18:08 |
| sean-k-mooney | by just checkign for the service role on the standard token | 18:08 |
| gmaan | whoami-rajat_: just imagine one scenario. cinder calling to glance will ALWAYS pass the policy. so glance policy is basically noop | 18:08 |
| gmaan | send_service_user_token has to be true always irrespective of RBAC, as you know - https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html | 18:09 |
| whoami-rajat_ | I understand and I'm not questioning that, but cinder doesn't support the new way to configure a glance section, read from it and pass role:[service] in request | 18:10 |
| whoami-rajat_ | and i doubt it does for nova either, haven't tried that | 18:10 |
| whoami-rajat_ | so it puts cinder in a condition where we can't really adopt the service role | 18:11 |
| sean-k-mooney | there is code for nova | 18:11 |
| gmaan | whoami-rajat_: oh, yeah that's true for glance. but It does not for nova - https://github.com/openstack/cinder/blob/master/cinder/compute/nova.py#L54-L59 | 18:11 |
| sean-k-mooney | whoami-rajat_: you can use the service user section or keystone_auth section or nova section in the absence of a glance section | 18:11 |
| gmaan | and this is where it is set in conder conf by devstack https://zuul.opendev.org/t/openstack/build/c3c5a139509b47748977f00985b18d2e/log/controller/logs/etc/cinder/cinder_conf.txt#74-85 | 18:11 |
| whoami-rajat_ | ah yes, because we used to send the admin request to nova for operations, now that admin creds with be switched to service one | 18:12 |
| sean-k-mooney | whoami-rajat_: exactly | 18:12 |
| whoami-rajat_ | yeah there was no use case for glance so we never did it | 18:12 |
| whoami-rajat_ | so what would be the next steps here? | 18:13 |
| whoami-rajat_ | Cinder can't really adopt the new location APIs then, at least in 2025.2 | 18:13 |
| sean-k-mooney | the best outcome woudl be to add a new galnce section adn fallback to the keystone_auth or service_user section when not defiend | 18:13 |
| whoami-rajat_ | if we revert the glance changes ^ which i think now is right to do | 18:13 |
| gmaan | whoami-rajat_: sean-k-mooney before going to next step, I would like to know how it was working in stable/2024.2 where glance policy is same as sean-k-mooney revert and cinder failing in revert - https://github.com/openstack/glance/blob/stable/2024.2/glance/policies/base.py#L114 | 18:13 |
| sean-k-mooney | both of those will have the corect roels | 18:13 |
| whoami-rajat_ | in 2024.2, we didn't adopt the location APIs | 18:14 |
| gmaan | ohh | 18:14 |
| whoami-rajat_ | so the feature in glance was merged in 2024.2 but we adopted it in 2025.2 (we=nova and cinder) | 18:14 |
| gmaan | got it | 18:14 |
| sean-k-mooney | the nova change mergd before the glance plicy change however right | 18:15 |
| whoami-rajat_ | yes | 18:15 |
| whoami-rajat_ | the policy change is recent, last week | 18:15 |
| gmaan | best way to not break user and provide option to adopt new way also can be: | 18:15 |
| sean-k-mooney | nova worked because we had an "admin" client | 18:15 |
| sean-k-mooney | with the service role to use | 18:15 |
| gmaan | 1. modify glance policy to service + admin right : this will allow cinder talk to glance with user token as it is currently | 18:16 |
| gmaan | 2. add keystoneauth service user conf option in glance section in cinder.conf | 18:16 |
| gmaan | 3. cinder pass that service user to glance which has service role | 18:16 |
| gmaan | 4. ask operator to configure the same in their deployment via releasenotes or doc | 18:17 |
| whoami-rajat_ | 3 and 4 could be the same cinder patch, which i can work on | 18:17 |
| gmaan | 5, once we know operator are ok (or at least after one SLURP), make glance API to role:service only | 18:17 |
| whoami-rajat_ | sounds good to me | 18:18 |
| sean-k-mooney | that effectivly what we are doing in the nvoa changes for the external events api ectrs | 18:18 |
| gmaan | yes, even we have the service user config option available for so ling | 18:19 |
| sean-k-mooney | so yes i think thiat is the correc approch as well | 18:19 |
| whoami-rajat_ | and if possible, can we document all the details we've discussed here in some RBAC doc, it's really confusing to know the "right" way to adopt a new thing like SRBAC which created the confusion for me at least | 18:19 |
| gmaan | whoami-rajat_: I can propose the changes if you are ok and help in review? bit if you want to do that also fine | 18:19 |
| sean-k-mooney | one thing to note | 18:19 |
| sean-k-mooney | yuo can achive the same effect without have per service config seciton with auth info | 18:20 |
| sean-k-mooney | nova's approch si way more flexible and i think cleaner | 18:20 |
| whoami-rajat_ | gmaan, sure, that will be faster as i can be one of the cores approving things | 18:20 |
| gmaan | whoami-rajat_: yeah, agree. that is my bad not to have proper doc for service role until I started working on those in nova, But I will do that as part of RBAC goal champion | 18:20 |
| gmaan | whoami-rajat_: cool | 18:20 |
| sean-k-mooney | but watcher ueses the keyston_authoken user/password for all service eclients | 18:21 |
| sean-k-mooney | im not sayint that ig the correct thing to do but you already need a cinder user in that section and it should have the service role | 18:21 |
| gmaan | sean-k-mooney: yeah, we can do that but we need to formalize that in most of the services. and I am not sure if there are use case of per service user permission in any demployment or they are ok with same user for all serviecsd | 18:21 |
| sean-k-mooney | i think we shoudl not make that default | 18:22 |
| gmaan | nova also has per service config users | 18:22 |
| sean-k-mooney | having a per service config section i think is better | 18:22 |
| gmaan | yeah, do not know what use we can break | 18:22 |
| sean-k-mooney | but you could have one fallback to the other if not configured | 18:22 |
| gmaan | ok, let me propose the changes today and will add you both as reviewer. | 18:23 |
| gmaan | sean-k-mooney: you want me to do it in your glance revert or separate one as this is more than revert and add admin right also with serviec role? | 18:23 |
| sean-k-mooney | gmaan: that valid. i have alreayd modifed it once. its up to you if you want to review the review/changeid go for ti | 18:24 |
| whoami-rajat_ | modifications in the revert might not be clean and confuse people doing blame in the future, can we go for a new patch? | 18:24 |
| sean-k-mooney | otherwise i can abandon it in favor of yours | 18:24 |
| whoami-rajat_ | gmaan, just to be sure, you will be working on the cinder patch as well right? to use [glance] config section | 18:25 |
| gmaan | ok let's do with new patch | 18:25 |
| gmaan | whoami-rajat_: yes, whole series + devstack one and testing it together like I did for nova | 18:25 |
| whoami-rajat_ | okay, thanks! | 18:25 |
| whoami-rajat_ | thanks again gmaan and sean-k-mooney for the details, I will go now, let me know when the glance and cinder patches are ready and i can help in merging them | 18:26 |
| gmaan | thanks, might be late for you | 18:27 |
| whoami-rajat_ | generally I've stopped working late now but this was important so :D | 18:28 |
| whoami-rajat_ | thanks again! | 18:28 |
| gmaan | good for you :) | 18:29 |
| sean-k-mooney | dansmith: so im more or less +w but before i hit it do you want to make this chagne https://review.opendev.org/c/openstack/placement/+/945465/comment/b1e034dd_f7b0b442/ or will i just approve as is | 19:10 |
| sean-k-mooney | dansmith: the wrodign change is defintly minor enouch that i dont think it needs a respon and gibi resolved there nit when they +2'd | 19:12 |
| sean-k-mooney | so in the absence of a prefence one way or another ill add +w before i finish for today | 19:13 |
| sean-k-mooney | but jsut said i woudl ask | 19:13 |
| dansmith | yeah, I dunno, I remember trying to figure out what to say there.. "does not increase existing overage" sounds a bit weird to me, even though I know what you mean | 19:13 |
| dansmith | my preference is to +W so the code is right, and we can FUP the log text if we want | 19:13 |
| sean-k-mooney | ya same that waws the second time i wrote that | 19:13 |
| sean-k-mooney | ack ill do that so | 19:13 |
| sean-k-mooney | done ok im going to try and finsin in the next 15 mins or so. i assume your going to backport those at some point | 19:15 |
| sean-k-mooney | it could be nice to include that in 2024.1 before it goes unmaintained but that wont happen until 2025.2 is released so there si a little time still | 19:16 |
| dansmith | yeah, should be backported | 19:25 |
| dansmith | I guess I dunno how far it really needs, I was thinking just to 2025.1 | 19:26 |
| opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | 19:27 |
| sean-k-mooney | i woudl say what is ever open when you get aroudn to it but 2025.1 is a good baseline | 19:27 |
| sean-k-mooney | by open i mean still stable/* | 19:28 |
| sean-k-mooney | gmaan: same question to you https://review.opendev.org/c/openstack/nova/+/957578/comment/2b782393_1a20e07c/ | 19:32 |
| opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | 19:32 |
| sean-k-mooney | im +2 i can +w but if you feel like adressing the final nit then im ok with fast approving or having dan proxy | 19:33 |
| opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | 19:34 |
| gmaan | dansmith: sean-k-mooney ^^ updated, I need to fix api-ref failure also. so this is updated one now | 19:34 |
| sean-k-mooney | ah yes stephsn sample split patch merged | 19:34 |
| gmaan | yeah :) | 19:34 |
| sean-k-mooney | i was wonderign what the prior conflict was | 19:35 |
| gmaan | dansmith: sean-k-mooney thanks. can you please review this devstack change also which is needed but tempest service role tests https://review.opendev.org/c/openstack/devstack/+/958612 | 19:47 |
| sean-k-mooney | im actully going to finish reviewing the first change in the sev serice but yes i can aftger | 19:51 |
| sean-k-mooney | then ill call it a day. | 19:52 |
| sean-k-mooney | my priorty tomorrwo will be to try and finish hte sev serise adn maybe the provider.yaml one | 19:52 |
| gmaan | thanks | 19:53 |
| sean-k-mooney | ok its litrally jsut adding thr service role | 19:53 |
| gmaan | yeah, quick one :) | 19:53 |
| sean-k-mooney | im +2 bnut shoud there be a comment above | 19:53 |
| sean-k-mooney | or shoudl you also mention that the service role is added in 2025.2 | 19:54 |
| sean-k-mooney | basicly im wonderign why you left the first comment | 19:54 |
| gmaan | i might just missed that, i can fix later once touching that file for related things | 19:54 |
| sean-k-mooney | ack | 19:55 |
| sean-k-mooney | i was just wonderign is there a convention that i shoudl be reviewing for | 19:55 |
| sean-k-mooney | like in nova-next we sometime add comment when testing a future default so we know we can drop it form the job when it actully becomes the default | 19:55 |
| sean-k-mooney | is noting the manager role so you can knwo when tempst can depend on it ? | 19:56 |
| gmaan | yeah, that is helpful specially to know when to drop those things once they are in all supported releases | 19:56 |
| sean-k-mooney | ack | 19:57 |
| sean-k-mooney | ok first patch doen and it looks ok but i defintly dont have the brain power to go deeper in teh sev series today | 20:18 |
| sean-k-mooney | ill try an complete it tomorrow | 20:18 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | 23:50 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | 23:50 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | 23:50 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | 23:50 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Purge nested SEV RPs when SEV is disabled https://review.opendev.org/c/openstack/nova/+/958626 | 23:51 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!