| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-02-27 | |||
| 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 | |
| 20:12:46 | dansmith | so is my complaint about the test not actually asserting the secret ephemeral-ness still valid? | |
| 20:13:12 | melwitt | I haven't read all of them yet but I will check | |
| 20:13:28 | dansmith | if it was doing that, I would have known that I was (indeed) missing something.. well, I'd like to think I would :) | |
| 20:13:46 | dansmith | I went looking at the tests to see if you were covering that case when I didn't see ->host and didn't see any such assertion | |
| 20:15:20 | melwitt | I can't remember if ephermeral-ness is/can be asserted in the func tests. I have those assertions in the whitebox tests but I need to remind on the func tests | |
| 20:39:26 | opendevreview | melanie witt proposed openstack/nova master: testing: Run functional tests under [testenv:cover] https://review.opendev.org/c/openstack/nova/+/975346 | |
| 21:04:30 | sean-k-mooney | for what its worth we discussed doing ^ in the past and ever got aroudn to it | |
| 21:05:00 | sean-k-mooney | one of the open question was if we wanted to have it be 2 targets or just one | |
| 21:05:10 | sean-k-mooney | but i didnt really have a prefence either way | |
| 21:18:02 | rm_work[m] | Hey, we're having trouble with nova (2025.2) and using TLS DB connection (I believe that's what is causing this error, at least): https://paste.opendev.org/show/booEwPakhOsPuP7Ws5Ul/ | |
| 21:18:23 | rm_work[m] | is this a known issue? or maybe I have the root cause wrong | |
| 21:19:16 | gmaan | melwitt: finished the vtpm tempest test review, do you have devstack change or nova job change where it is enabled and tests running https://review.opendev.org/c/openstack/tempest/+/957475 | |
| 21:20:10 | gmaan | ah got it, this one https://review.opendev.org/c/openstack/nova/+/957477 | |
| 21:21:13 | melwitt | yep you got it, thanks for looking | |
| 21:24:15 | gmaan | are you planning to remove the DNM from it? bcz before merging tempest tests, we need at least one job that run those tests | |
| 21:27:08 | melwitt | gmaan: yeah I need to do that also | |
| 21:27:18 | gmaan | ack, thanks | |
| 21:31:53 | gmaan | I will check the whitebox test later in evening or on Monday | |
| 21:51:09 | sean-k-mooney | rm_work[m]: that issue is form eventlet/greenlet depending on the version you are using it might be a know issue that was resolved. there were a few errors like that but i dont recall off the top of my head exactly hwen they were fixed. ill note that nova does not test with gunicorn so while it should work if you run it in eventlt mode | |
| 21:51:45 | sean-k-mooney | i.e. gunicorn myapp:app -k eventlet --worker-connections 1000 | |
| 21:52:19 | rm_work[m] | ok well I discovered export OS_NOVA_DISABLE_EVENTLET_PATCHING=true lol | |
| 21:52:26 | rm_work[m] | seems to work mostly on 2025.2 | |
| 21:52:48 | rm_work[m] | oh I didn't realize it also needed eventlet mode <_< | |
| 21:53:29 | sean-k-mooney | we implment scater gatther for some api request that go across multiple cells | |
| 21:53:38 | sean-k-mooney | that is the only thing that uses it in the api | |
| 21:54:22 | sean-k-mooney | but ya you could swap to the non eventlet backens for grunicorn | |
| 21:55:18 | rm_work[m] | hmmm worker-class eventlet doesn't seem to help | |
| 21:55:31 | rm_work[m] | so yeah am trying with no eventlet | |
| 21:55:42 | rm_work[m] | will just switch to 2026.1 as soon as it's released too heh | |
| 21:55:57 | rm_work[m] | tempted to rebuild all our stuff on master <_< but some pushback from above heh | |
| 21:56:22 | sean-k-mooney | if you do let use know how it goes | |
| 21:56:40 | sean-k-mooney | yesterday we meged the ablity to run nova-compute without eventlet | |
| 21:56:46 | rm_work[m] | did notice some cells issues possibly, digging in first before I say anything concrete | |
| 22:01:57 | rm_work[m] | looks like the issue is nova not supporting a comma-separated RMQ transport URL for multiple RMQs? do we need to use a loadbalancer or a single RMQ? | |
| 22:02:39 | sean-k-mooney | there si a wasy to use multiple server but we recommend a loadblancer | |
| 22:02:46 | rm_work[m] | ok | |