Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-02-27
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
19:28:19 sean-k-mooney ok ill make a note but im not agisnt that propsoal
19:29:03 stephenfin subtest is awsome too. table-driven tests are one of Go's better ideas
19:30:30 sean-k-mooney actully
19:30:42 sean-k-mooney we have code in the verison negoication to do that already
19:31:12 sean-k-mooney https://github.com/openstack/python-novaclient/blob/master/novaclient/api_versions.py#L307-L308
19:31:25 sean-k-mooney if you use discover_version(client, requested_version)
19:31:39 sean-k-mooney ti will try to do the right thing
19:54:09 opendevreview Zhan Zhang proposed openstack/nova master: Change live_migration_downtime_delay to float https://review.opendev.org/c/openstack/nova/+/978255
19:59:13 opendevreview Zhan Zhang proposed openstack/nova master: Change live_migration_downtime_delay to float https://review.opendev.org/c/openstack/nova/+/978255
20:05:02 melwitt dansmith: yeah I had assumed there wouldn't be enough time for the conversion one. but it's also only needed for converting to user/host from deployment or deployment to user/host and we didn't merge live migration of 'deployment' yet
20:05:38 dansmith yeah I'm a bit confused about user->host, see my comment
20:07:08 melwitt yeah I'm looking through your review comments. tl;dr is there is no conversion needed for user -> host or vice versa because those both have a user-owned secret. nova service user is not the secret owner
20:08:14 dansmith right, but .. oh, maybe just the act of the resize will stab it into libvirt on the destination host as ephemeral=false?
20:08:40 melwitt the conversion is only if you are looking to go from a user owned secret to a nova service user owned secret or vice versa. and the logic I used for that is "side-by-side" until revert or confirm
20:08:44 melwitt yeah it's just the metadata that will make it create it with the right properties
20:08:50 melwitt it's "automatic"
20:09:04 dansmith " These two steps will be done automatically during _create_guest(), so nothing needs to be done here." derp
20:09:27 dansmith okay sorry I missed that ^ and was expecting to see something but yeah, makes sense
20:09:58 dansmith so, erm, what happens in resize-to-same-host?
20:10:03 melwitt the complicated thing is if you have a user owned secret (user or host) and resize wants to go to 'deployment'. so the logic I used is, keep the existing secret and create a NEW nova service user owned secret with the same passphrase (string) and then based on confirm or revert delete the one we no longer need
20:10:17 dansmith yeah, I understand the to/from deployment complexity
20:11:21 melwitt resize to same host still involves destroy/create guest domain I assume, so it works the same way
20:11:49 dansmith okay
20:12:19 melwitt the libvirt secret lifecycle matches the domain lifecycle, I think. (I will double check all of it). so it is sort of "regularly" destroyed and recreated
20:12:26 dansmith melwitt: yeah, yeah, okay

Earlier   Later