Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-02-27
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
22:02:58 rm_work[m] for reference: https://paste.opendev.org/show/b9nwUz4doBA2Kd97rcBs/
22:03:56 sean-k-mooney driver://[user:pass@]host:port[,[userN:passN@]hostN:portN]/virtual_host?query
22:03:58 sean-k-mooney its like that
22:05:41 sean-k-mooney rabbit://rabbitmq:password@127.0.0.1:5672,rabbitmq:password@127.0.0.2:5672/?
22:06:05 sean-k-mooney you do not repeat the schema part just the user/password/host/port part
22:06:16 sean-k-mooney https://docs.openstack.org/oslo.messaging/latest/reference/transport.html
22:06:21 sean-k-mooney this is just direclty form oslo
22:08:30 rm_work[m] hmmm i think we do that already
22:08:34 rm_work[m] rabbit://openstack-rabbitmq-server-0.openstack-rabbitmq-nodes.infra.svc.cluster.local:5671,openstack-rabbitmq-server-1.openstack-rabbitmq-nodes.infra.svc.cluster.local:5671,openstack-rabbitmq-server-2.openstack-rabbitmq-nodes.infra.svc.cluster.local:5671/nova
22:08:41 rm_work[m] seems to match
22:08:44 rm_work[m] we use TLS so no user/pass
22:08:58 rm_work[m] it's having issues splitting in the cells side
22:09:15 rm_work[m] see the paste
22:09:36 sean-k-mooney i thin the user is requried
22:09:56 rm_work[m] hmmmm
22:09:59 sean-k-mooney although im not sure
22:10:04 rm_work[m] it works with other services
22:10:11 rm_work[m] tracking down the exact line on the nova side, one sec
22:10:24 sean-k-mooney https://docs.openstack.org/nova/latest/admin/cells.html#template-urls-in-cell-mappings
22:10:31 sean-k-mooney that is the docs for the cell specific part
22:10:37 rm_work[m] I think https://opendev.org/openstack/nova/src/branch/stable/2025.2/nova/objects/cell_mapping.py#L100 is just trying to parse the whole URL without splitting
22:10:42 rm_work[m] but trying to trace backwards
22:10:57 rm_work[m] reading your doc quick now
22:11:56 sean-k-mooney i think to make it work in the cell mappign you have to use the template url syntax
22:12:12 sean-k-mooney but the only instlal i knowof that used that or multipel hosts was tripleo
22:12:23 sean-k-mooney so i have evictine dmost of my understanding of how that works
22:12:32 sean-k-mooney all the rest just used haproxy
22:12:52 rm_work[m] hmmm ok looking, not clear on how to put the other hostnames in that template, or if that even really gives us multiple
22:13:04 sean-k-mooney in the template you dont
22:13:21 sean-k-mooney in teh transport url you do but in the template you only have one host
22:14:05 rm_work[m] yeah ok so LB it is prolly, since we expect these may individually go down due to like k8s evictions/etc

Earlier   Later