| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-02-27 | |||
| 00:28:05 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973 | |
| 00:28:05 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972 | |
| 00:28:06 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | |
| 00:28:06 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | |
| 01:03:54 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972 | |
| 01:03:54 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor memory encryption trait logic for extensibility https://review.opendev.org/c/openstack/nova/+/967971 | |
| 01:03:55 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | |
| 01:03:55 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973 | |
| 01:03:56 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | |
| 05:39:55 | opendevreview | Merged openstack/nova master: Accept an empty key for addresses https://review.opendev.org/c/openstack/nova/+/978089 | |
| 10:59:29 | opendevreview | Balazs Gibizer proposed openstack/nova master: Remove eventlet from CacheConcurrencyTestCase https://review.opendev.org/c/openstack/nova/+/970069 | |
| 10:59:30 | opendevreview | Balazs Gibizer proposed openstack/nova master: Remove eventlet from libvirt/volume/test_mount https://review.opendev.org/c/openstack/nova/+/970071 | |
| 10:59:30 | opendevreview | Balazs Gibizer proposed openstack/nova master: Remove eventlet from libvirt/test_driver https://review.opendev.org/c/openstack/nova/+/970070 | |
| 10:59:31 | opendevreview | Balazs Gibizer proposed openstack/nova master: Speed up RetryDecorator in unit test https://review.opendev.org/c/openstack/nova/+/975443 | |
| 11:12:01 | r-taketn | I have updated sev refactoring series. However, is merging these changes currently restricted by Feature Freeze? | |
| 11:33:37 | gibi | r-taketn: we reached FF for Gazpacho. One can argure that your series is more of a refactor than a feauture. But I defer to Uggla to decide if we need to wait with your series until master is open for the H cycle | |
| 12:04:09 | r-taketn | Except for the latest patch, I believe this series falls within refactoring. It would be helpful for me to continue the review, but I’ll wait for a decision from Uggla. Thank you for a clarification. | |
| 12:04:35 | opendevreview | Merged openstack/nova master: TPM: fixups for live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/976316 | |
| 13:28:03 | opendevreview | Merged openstack/nova master: Destroy scatter_gather in conductor https://review.opendev.org/c/openstack/nova/+/977055 | |
| 13:37:00 | nicolairuckel | I'd like to backport my NVRAM patch. Is there any documentation on how to do that? | |
| 13:47:12 | gibi | nicolairuckel: in general backporting bugs are simply. You need to git cherry-pick -x to the youngest stable branch first then when that is done you can cherry-pick from that branch to the next one. Not all patches are accepted as backports on stable. In general we don't allow feature backports, or backports that has external interface impacts like API impacts or DB schema changes. | |
| 13:47:30 | gibi | elodilles: ^^ | |
| 13:55:05 | elodilles | nicolairuckel: what gibi said :) feel free to ping me if you have any further question or need a review for your backport | |
| 14:41:03 | Uggla | So from my side, I’m fine to proceed and not wait for master to reopen for the H cycle. | |
| 14:41:03 | Uggla | Given that, I’d prefer we take advantage of the current momentum and continue the review with the goal of merging it during Gazpacho, if possible. This refactoring will also make the upcoming confidential computing work (SEV-SNP and TDX) easier to integrate and reason about. | |
| 14:41:03 | Uggla | gibi, r-taketn, I agree that this series is primarily a refactoring rather than a feature change. | |
| 14:45:03 | LarsErikP | sean-k-mooney: any more traction here? :P https://review.opendev.org/c/openstack/nova/+/916409 | |
| 14:49:29 | gibi | Uggla: thanks. When r-taketn is back we should clarify with them that then we have an extra two weeks for the refactor | |
| 14:49:52 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Object changes https://review.opendev.org/c/openstack/nova/+/978209 | |
| 14:49:59 | sean-k-mooney | LarsErikP: nope | |
| 14:50:21 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Scheduler changes https://review.opendev.org/c/openstack/nova/+/971176 | |
| 14:50:42 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Libvirt NUMA Migrate https://review.opendev.org/c/openstack/nova/+/971177 | |
| 15:07:00 | opendevreview | Joan Gilabert proposed openstack/nova-specs master: Repropose and update cyborg vGPU (mdev) support https://review.opendev.org/c/openstack/nova-specs/+/967515 | |
| 15:08:48 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Scheduler changes https://review.opendev.org/c/openstack/nova/+/971176 | |
| 15:11:09 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Libvirt NUMA Migrate https://review.opendev.org/c/openstack/nova/+/971177 | |
| 17:41:03 | tkajinam | hmm so nova no longer returns response body and that broke novaclient https://bugs.launchpad.net/python-novaclient/+bug/2142879 | |
| 17:41:51 | opendevreview | Merged openstack/nova master: api: Add ability to filter flavors by name https://review.opendev.org/c/openstack/nova/+/958748 | |
| 17:43:42 | sean-k-mooney | tkajinam: that is intentional i think the api is now async | |
| 17:44:20 | sean-k-mooney | tkajinam: i didnt review the patch much but i belive the schema for 2.101 states the body shoudl be empty | |
| 17:44:49 | tkajinam | I'm still confused because https://review.opendev.org/c/openstack/nova/+/971068/9/api-ref/source/os-volume-attachments.inc#109 says the body should be empty but | |
| 17:45:17 | tkajinam | oh. wait. I see. | |
| 17:45:33 | sean-k-mooney | heat need to be modifyed to supprot 2.101 it shoudl not be useing latest blindly | |
| 17:45:35 | tkajinam | but I'm wondering how the volume attachment should be monitored then ? | |
| 17:45:56 | tkajinam | I mean we don't know which record is exactly being created | |
| 17:46:57 | sean-k-mooney | i dont recall the spec off hand https://github.com/openstack/nova-specs/blob/master/specs/2026.1/approved/async-volume-attachments.rst | |
| 17:47:05 | sean-k-mooney | but it shoudl cover that | |
| 17:47:49 | sean-k-mooney | my guess is via the instance action events? | |
| 17:48:20 | sean-k-mooney | i.e. use the reqeust id to identify the instnace action event and wait for it to be complete | |
| 17:48:34 | sean-k-mooney | althogh your aware of the exisitng bug with that flow | |
| 17:48:41 | sean-k-mooney | so the only relyable way | |
| 17:48:53 | sean-k-mooney | woudl be to watch the volume via nova show | |
| 17:49:24 | sean-k-mooney | the volume wont be listed in the show responce until its attached i belive | |
| 17:49:44 | sean-k-mooney | but again i didnt really review this in detail | |
| 17:50:02 | gmaan | yes, it will not return attachment response, it will return 202 only like other asyn API | |
| 17:50:26 | gmaan | I am reviewing the tempest change which is good way to see what all changed - https://review.opendev.org/c/openstack/tempest/+/977952 | |
| 17:51:03 | tkajinam | so is there any plan to fix novaclient ? | |
| 17:51:15 | tkajinam | I can update heat to adopt to the change but the create_server_volume API is just broken | |
| 17:51:22 | tkajinam | with 2.101 | |
| 17:51:24 | sean-k-mooney | no | |
| 17:51:34 | gmaan | I think novaclient use latest microversion so that is expected behaviour | |
| 17:51:36 | sean-k-mooney | nova client is frozen for both python and cli usage | |
| 17:51:40 | gmaan | yeah | |
| 17:51:51 | tkajinam | do you mean that ugly TypError is expected ? | |
| 17:51:51 | sean-k-mooney | it does not suprpot anythign over 2.96 i think | |
| 17:52:24 | sean-k-mooney | tkajinam: nova client hsoudl not be used with any microveron beyond its max verion | |
| 17:52:46 | gmaan | ohk if it is TypeError then yes it is broken but it should be fixed in osc if there too it is broken | |
| 17:53:03 | gmaan | stephenfin: did not officially deprecated that? | |
| 17:53:12 | tkajinam | sean-k-mooney, do you know where that max version is defined ? | |
| 17:53:22 | sean-k-mooney | its in the client code one sec | |
| 17:53:33 | tkajinam | novaclient/__init__.py:API_MAX_VERSION = api_versions.APIVersion("2.96") | |
| 17:53:35 | tkajinam | ok | |
| 17:53:48 | sean-k-mooney | yep ^ | |
| 17:53:52 | gmaan | tkajinam: https://github.com/openstack/python-novaclient/blob/e00ed698af04e2c5b78db3516d26c79ffed9851f/novaclient/__init__.py#L28 | |
| 17:54:22 | sean-k-mooney | tkajinam: that why we move watcher to the sdk this cycle for what its worth | |
| 17:54:23 | gmaan | then why it is broken? and how it requested with 2.101? | |
| 17:54:43 | sean-k-mooney | gmaan: novaclient does nto clamp internally | |
| 17:54:58 | sean-k-mooney | but this i htink is more of a heat bug in that heat should nto just be using latest | |
| 17:55:15 | sean-k-mooney | it shoudlbe passing the expected micoverion for each call | |
| 17:55:19 | gmaan | i see, got it. maybe we should through error if requested with >2.96 | |
| 17:55:27 | gmaan | that will be more explicit | |
| 17:55:31 | sean-k-mooney | to get the behvior it is coded to supprot | |
| 17:57:29 | tkajinam | https://opendev.org/openstack/heat/src/commit/f110fc56492022f71b38a882c9a1ea60ba4da6d4/heat/engine/clients/os/nova.py#L95-L105 | |
| 17:58:36 | sean-k-mooney | that looks ok its the call site where your actully doing the attachment that is likely incorrect | |
| 17:59:00 | sean-k-mooney | https://opendev.org/openstack/heat/src/commit/f110fc56492022f71b38a882c9a1ea60ba4da6d4/heat/engine/clients/os/nova.py#L684-L701 | |
| 18:00:18 | sean-k-mooney | i dont see a microverison being spcifed there | |
| 18:00:42 | tkajinam | in heat we use common microversion for all api calls | |
| 18:00:54 | sean-k-mooney | ya that is entirly broken | |
| 18:00:57 | tkajinam | and the version is detected by API call. by default is uses the latest one available | |
| 18:01:04 | sean-k-mooney | that is not somethign that applciation can or shoudl ever do | |
| 18:01:17 | tkajinam | I'll update heat to cap the version according to the version defined there | |
| 18:01:18 | sean-k-mooney | its also not safe to do in general | |
| 18:02:01 | gmaan | yeah, microversion does not provide backward compatible, it needs to be on opt basis instead of latest by default | |
| 18:02:08 | tkajinam | it might be ideal to define expected api version for each call, though I don't know if that's really feasible for people to check every single microversion and check whether any single call can be bumped | |
| 18:02:24 | tkajinam | given we have 100+ versions now | |
| 18:02:29 | sean-k-mooney | well that is how our api contract is defiend | |
| 18:02:48 | sean-k-mooney | we add a new microverion if we change behvior and keep the old micoverion workign the way they always didi | |
| 18:07:44 | tkajinam | I know, though I sometimes wonder if we can consider bumping "min supported" version several years after 2.2 was created | |
| 18:08:24 | sean-k-mooney | i am not agaisnt that but where i woudl like to bump to an other woudl differ widely | |
| 18:08:34 | sean-k-mooney | tkajinam: heat can | |
| 18:08:38 | sean-k-mooney | indepnetn of nova | |