Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-05
17:17:24 stephenfin Looks like the quota class show API doesn't have any expected error codes :/ https://github.com/openstack/nova/blob/968965cc77c6932eb67cc36a539f108c73d50ea0/nova/api/openstack/compute/quota_classes.py#L89
17:18:06 sean-k-mooney https://docs.openstack.org/nova/latest/contributor/microversions.html#id3
17:18:19 sean-k-mooney """
17:18:21 sean-k-mooney The exception to not needing a microversion when returning a previously unspecified error code is the 400, 403, 404 and 415 cases. This is considered OK to return even if previously unspecified in the code since it’s implied given keystone authentication can fail with a 403 and API validation can fail with a 400 for invalid json request body. Request to url/resource that
17:18:23 sean-k-mooney does not exist always fails with 404. Invalid content types are handled before API methods are called which results in a 415."""
17:18:38 sean-k-mooney this should be a 400
17:18:53 stephenfin there wasn't a previously unspecified error code though
17:19:00 stephenfin as in, we don't see HTTP 500
17:19:12 stephenfin which I thought was the only case where a microversion wasn't needed
17:19:15 sean-k-mooney that isnt requried
17:19:27 stephenfin (that and returning HTTP 410 (Gone) where we could no longer support a service)
17:19:40 sean-k-mooney we have estiblishted several time sthat you shoudln not need ot opt into a bug fix
17:22:05 sean-k-mooney stephenfin: by the way if you read the comment thread https://review.opendev.org/c/openstack/nova/+/978494/comments/6ba93b6c_a0707c41 i said i was ok if we add a fixeme comment to adress this proplry later
17:22:35 sean-k-mooney i would also prefer if it was not closes-bug but related-bug
17:22:43 sean-k-mooney buecause it does not close it in my view
17:22:49 sean-k-mooney but i care about that less
17:27:15 opendevreview Stephen Finucane proposed openstack/nova master: WIP: api: Block non-default quota class sets https://review.opendev.org/c/openstack/nova/+/979033
17:27:26 stephenfin sean-k-mooney: mock up of what I think you're after ☝️
17:28:25 sean-k-mooney ya basiclly i was also debating if we woudl encoded it in the open api schema as well
17:28:45 nicolairuckel dansmith, elodilles: I'm not sure where exactly the changes came from though. One is this (https://opendev.org/openstack/nova/commit/650772d97efe98e578c18b8268b3bbed63ac4d18) and the other one removed a line so I can't just use git blame (or I just don't know how)
17:29:09 sean-k-mooney stephenfin: but something like that
17:29:56 stephenfin we don't currently have schemas for request parameters (only ironic does for now), but if we did then that should be added, yes
17:30:05 stephenfin *request path parameters
17:30:09 sean-k-mooney ah ok
17:30:17 sean-k-mooney then ya ignore that for now
17:34:02 nicolairuckel ah, this is the other one: https://opendev.org/openstack/nova/commit/880019baafe23f46e59dee7debadf49b9177dc70
17:40:14 opendevreview Nicolai Ruckel proposed openstack/nova stable/2025.2: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/978908
17:40:55 opendevreview Nicolai Ruckel proposed openstack/nova stable/2025.2: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/978908
17:47:43 nicolairuckel I added my additional changes to the commit message. I'm not sure if it would make sense to backport those two patches as well.
17:47:55 nicolairuckel But I guess that can be discussed in the patch. :)
17:49:01 sean-k-mooney i commeted in the patch
17:49:25 sean-k-mooney you shoudl backport https://review.opendev.org/c/openstack/nova/+/961734/4 and the fix https://review.opendev.org/c/openstack/nova/+/962007
17:51:21 sean-k-mooney at least that woudl be my inclination as i think we will want to backprot that to fix https://bugs.launchpad.net/nova/+bug/2125030 ingeneral
17:51:52 sean-k-mooney melwitt: is there a reason ^ has not been backported beyound time?
17:53:16 melwitt sean-k-mooney: no there is no reason and in fact I think it should be backported. there is also a func test patch that goes with it
17:53:38 sean-k-mooney yep nicolairuckel was pullingin part of the funtional test patch
17:53:39 melwitt I just didn't think of it at the time
17:53:59 sean-k-mooney to resolve a conflict in backing the fix for vtpm rebot
17:54:17 yuval_ hey I checked the iothread thing - machine show no difference in iops. is there some flag I need to enalble? I see the iothread in the xmldump
17:54:26 melwitt yeah that bug fix should be backported bc that bug can permanently damage a vtpm instance if a resize revert is done. it will destroy the barbican secret and then it's gone forever
17:54:57 yuval_ talking with claud - we are using not in the right way we need to assign the iothread to a block device
17:56:11 sean-k-mooney yuval_: the cange that was done this cycle we expect to not significaly increate th iops but rather impove the managablity of the vm (attach/detach infaces, start stop ectra) whne the qemu process is under load from high io
17:56:32 sean-k-mooney the disk io is still limited to the perfromace of 1 thread
17:56:56 sean-k-mooney but now that thread is not also runign the qemu monitor and other background tasks in addtion to io
17:57:05 sean-k-mooney so it shoudl impove a litell but not massively
17:57:33 sean-k-mooney yuval_: the block deivces will be assigne dby qemu automaticly
17:58:14 sean-k-mooney yuval_: its possibel to futher increase perfomce if we do allcoate more io thread and provide a dedicated one or multiple to block devices
17:58:32 sean-k-mooney that left for future work in the upcoming cycles
17:58:46 yuval_ I have tested iothreads in the past - it can improve performance alot
17:59:03 yuval_ thats why I am testing it - but the xml configuration was difference
17:59:19 yuval_ I need to assign iothread to the block device
18:00:06 yuval_ its a question how we assign those threads when block device is attach/detach
18:00:36 sean-k-mooney yep, and as i said we agred not to do that for this release
18:01:54 yuval_ got it thanks
18:02:06 yuval_ I will try to dig in see how that might be possible
18:02:56 sean-k-mooney the issue is there are several ways to do it with diffeern lvel of complexity
18:03:22 sean-k-mooney my current inlcidation is to keep it simple and use the defautliothread element https://libvirt.org/formatdomain.html#iothreads-allocation
18:03:58 sean-k-mooney alhtough you can also map disks indivutally
18:04:21 sean-k-mooney or at least storage contolers in the case of virtio scsi
18:05:14 sean-k-mooney we could for now explcitly add the iothread affinity to iothrad 1 to all disk
18:05:37 sean-k-mooney but i belive that shoudl be the effecite behvior we alerady get when we say nothign in this case
18:07:27 sean-k-mooney yuval_: if you fidn that is not the case file a bug and we can look to expclity do that mappign
18:09:06 yuval_ I will do some extra tests
18:19:42 opendevreview Nicolai Ruckel proposed openstack/nova stable/2025.2: Add functional reproducer for bug 2125030 https://review.opendev.org/c/openstack/nova/+/979041
18:42:16 nicolairuckel sean-k-mooney: First backport is ready
18:42:32 nicolairuckel Since they depend on each other I have to wait for the next one.
18:44:43 dansmith nicolairuckel: no, you should stack them all together
18:44:51 dansmith not squash, but stack
18:45:16 dansmith meaning, create your topic branch, cherry-pick the first, then the second, then the third.. then git-review and it will say "Submitting 3 commits, right?"
18:45:29 dansmith that's what you want, so we can see them all together as they'll land
18:46:53 nicolairuckel oh, I see
18:52:16 gmaan sean-k-mooney: stephenfin on non-default quota class, if it was allowed then schema change makes it 200->400 which is an API change. that is why i commented on tkajinam fix that let's fix the test + revert the schema change and later we will see how we can improve the API by seeing what exactly we are changing for users
18:55:07 gmaan sean-k-mooney: stephenfin: I am ok to land the nova fix but we need to fix the novaclient test also which is wrong https://review.opendev.org/c/openstack/python-novaclient/+/978254
18:59:43 nicolairuckel dansmith: I'm running the tests now and if that's successful I'll push my branch.
18:59:59 gmaan tkajinam: stephenfin +w on nova fix but let's fix the novaclient test also to test the 'default' quota class https://review.opendev.org/c/openstack/nova/+/978494
19:07:42 opendevreview Zhan Zhang proposed openstack/nova-specs master: Allow Operators to Launch VMs on Disabled Hosts https://review.opendev.org/c/openstack/nova-specs/+/979049
19:17:57 bryanfraschetti there would otherwise be interest in accepting this functionality
19:17:57 bryanfraschetti The current way out of this situation is to modify the db and mark the volume attachment as deleted in the Nova block_device_mapping table. To avoid manual DB access, I'm working to add this functionality to nova-manage via a command such as nova-manage volume_attachment remove <server_uuid> <volume_uuid>. I'd like to upstream the functionality and am wondering if there's any glaring problems with this idea or if
19:17:57 bryanfraschetti attachment record is not present in the cinder database at all.
19:17:57 bryanfraschetti Hi folks, I hope you're doing well! A few weeks ago I mentioned this bug: https://bugs.launchpad.net/nova/+bug/2141355, and was advised to try restarting the instances with the problematic volume attachments as well as try nova-manage volume_attachment refresh while the instances are turned off. I have found that this did not work as expected and my best guess is that the cleanup doesn't quite work because the
19:19:38 opendevreview Nicolai Ruckel proposed openstack/nova stable/2025.2: Add functional reproducer for bug 2125030 https://review.opendev.org/c/openstack/nova/+/979041
19:19:39 opendevreview Nicolai Ruckel proposed openstack/nova stable/2025.2: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/978908
19:19:40 opendevreview Nicolai Ruckel proposed openstack/nova stable/2025.2: Move cleanup of vTPM secret from driver to compute https://review.opendev.org/c/openstack/nova/+/979052
19:19:47 nicolairuckel dansmith: Like this?
19:27:54 melwitt nicolairuckel: the stack is good but on the last backport afaict there was a manual merge conflict resolution needed and those are to be referenced in the commit message of the backport i.e. https://docs.openstack.org/project-team-guide/stable-branches.html#conflicts I will mention this on the review
19:36:51 nicolairuckel interesting, I didn't merge anything manually there
19:37:33 nicolairuckel I wonder if its because of some of my Git settings.
19:39:17 melwitt yeah I noticed after I replied to you I see that the merge conflict content is included in your backport which it shouldn't be. so I wonder what kind of thing could have caused that to happen automatically? I have not experienced something like that before
19:42:25 nicolairuckel me neither
19:42:39 nicolairuckel I need to experiment a bit with that tomorrow
19:42:48 nicolairuckel but for now I want to just fix the patch :D
19:42:56 opendevreview Nicolai Ruckel proposed openstack/nova stable/2025.2: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/978908
19:43:56 melwitt sure. please do look into it later :)
19:44:06 nicolairuckel Thank you for looking into the patch
19:44:29 nicolairuckel I'll be busy with dinner now but I'll check later again.
20:43:24 opendevreview Zhan Zhang proposed openstack/nova-specs master: Allow Operators to Launch VMs on Disabled Hosts https://review.opendev.org/c/openstack/nova-specs/+/979049
#openstack-nova - 2026-03-06
00:58:20 opendevreview melanie witt proposed openstack/nova master: Add nova-vtpm job https://review.opendev.org/c/openstack/nova/+/978841
01:06:02 opendevreview melanie witt proposed openstack/nova master: Add nova-vtpm job https://review.opendev.org/c/openstack/nova/+/978841
01:14:30 melwitt looks like some new gate failure might be brewing "AttributeError: 'Parsed' object has no attribute 'config_format'" https://paste.opendev.org/show/bS87fFXvqOKODTRMllg4/ seen in https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-py313 and https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-docs&skip=0
01:15:19 melwitt oh yeah wow. everything red https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-pep8&skip=0

Earlier   Later