| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-02-27 | |||
| 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 | gibi, r-taketn, I agree that this series is primarily a refactoring rather than a feature change. | |
| 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 | So from my side, I’m fine to proceed and not wait for master to reopen for the H cycle. | |
| 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 | sean-k-mooney | it does not suprpot anythign over 2.96 i think | |
| 17:51:51 | tkajinam | do you mean that ugly TypError is expected ? | |
| 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 | |
| 18:10:06 | dansmith | melwitt: can we not pull the "enable conversion of secret modes" down in the stack and try to get it merged? | |
| 18:12:40 | dansmith | I guess maybe too late for FF | |
| 18:13:33 | tkajinam | I'll see if https://review.opendev.org/c/openstack/heat/+/978246 works | |
| 18:14:13 | tkajinam | there've been a few other problems I had to fix before I eventually encountered this. This cycle has been too exciting... | |
| 18:21:35 | opendevreview | Merged openstack/nova master: TPM: bump service version to enable live migration https://review.opendev.org/c/openstack/nova/+/975724 | |
| 18:37:12 | stephenfin | sean-k-mooney: tkajinam: wait, what's broken? | |
| 18:37:55 | gmaan | stephenfin: support of 2.101 in novaclient where it can handle the no response from volume attachment API | |
| 18:40:30 | gmaan | I will say it is not broken but not supported as planned | |
| 19:07:42 | sean-k-mooney | Uggla: https://meetings.opendev.org/irclogs/%23openstack-release/latest.log.html#openstack-release.2026-02-27.log.html#t2026-02-27T18:59:45 the change to python-novaclint to move it to indemepent and stop branching it from antelop has been implemtned in the release tooling | |
| 19:16:10 | opendevreview | Stephen Finucane proposed openstack/python-novaclient master: Add version foot protector https://review.opendev.org/c/openstack/python-novaclient/+/978254 | |
| 19:16:59 | stephenfin | gmaan: sean-k-mooney: tkajinam: ^ | |
| 19:17:03 | stephenfin | I think that's a reasonable change | |
| 19:17:41 | stephenfin | sean-k-mooney: my understanding (which that mail backs up) was that we were not adding support any more microversions but we would fix bugs | |
| 19:17:52 | stephenfin | *support for | |
| 19:19:03 | sean-k-mooney | and woudl only fix them on master no more relases :P | |
| 19:19:39 | sean-k-mooney | lookign at the history however the change to move it to indepentne and to sotp the brancches being created that we agreed for antelop was not actully implemnted | |
| 19:19:51 | stephenfin | that mail says nothing about not cutting releases 😅 | |
| 19:20:01 | stephenfin | > we agreed on changing the release model for novaclient to be independent so we can release anytime we need. | |
| 19:20:08 | stephenfin | that says the opposite ☝️ | |
| 19:20:11 | sean-k-mooney | we also had ptg dicsusion after that | |
| 19:20:36 | sean-k-mooney | there was nto ment ot be any automatic release | |