| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-02-27 | |||
| 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 | |
| 19:20:43 | sean-k-mooney | only as needed bugfix ones | |
| 19:21:09 | sean-k-mooney | so no automatic release at milestone 1 and rc1 | |
| 19:21:36 | stephenfin | that's fine, but that's not what I'm arguing | |
| 19:21:57 | stephenfin | I'm saying we can still cut releases. Whether they're automatic or not is a separate point | |
| 19:23:06 | stephenfin | the antelope PTG etherpad is here https://etherpad.opendev.org/p/nova-antelope-ptg and it says: | |
| 19:23:11 | stephenfin | > we don't want to deprecate novaclient bindings as we're willing to continue supporting feature parity between SDK and novaclient as operators/heat/whatever continue to use novaclient and don't have resources to make a big leap to SDK. | |
| 19:23:18 | stephenfin | that sounds like bauzas wording :) | |
| 19:23:45 | stephenfin | no, it's me actually | |
| 19:24:35 | sean-k-mooney | yep. since then we have had a pamdemic and the rise of our llm overlords | |
| 19:25:05 | sean-k-mooney | well the latter that was in 2022 | |
| 19:25:11 | sean-k-mooney | not the former | |
| 19:25:25 | sean-k-mooney | anyway the patch looks ok | |
| 19:25:43 | sean-k-mooney | im reading it again to be sure | |
| 19:27:13 | sean-k-mooney | so you decied to raise if its over the max supproted by the lib instead of clamp | |
| 19:27:20 | sean-k-mooney | i guess that is safer | |
| 19:27:48 | sean-k-mooney | althoguh clampign to 2.96 for client that used latest woudl still be semanticly valid | |
| 19:27:54 | stephenfin | I think so. Heat still needs to make changes but at least they'll fail immediately | |
| 19:28:17 | stephenfin | I thought about that, but if users says do X I don't think I should silently swap in Y | |