| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-05 | |||
| 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 | |
| 02:36:55 | haleyb | and i thought it was just a transient failure :( | |
| 03:06:08 | haleyb | https://github.com/tox-dev/tox/issues/3866 - just filed | |
| 08:12:37 | nicolairuckel | Are there any known problems in the CI with cinder at the moment? https://zuul.opendev.org/t/openstack/build/620bd5237b564976b4307c6f0c105d67 | |
| 08:12:52 | nicolairuckel | I want to make sure I didn't break anything before restarting the CI job. | |
| 09:14:51 | opendevreview | Ilia Baikov proposed openstack/nova master: compute: Pre-load flavor and system_metadata in init_host https://review.opendev.org/c/openstack/nova/+/979126 | |
| 09:15:52 | opendevreview | Ilia Baikov proposed openstack/nova master: compute: Pre-load flavor and system_metadata in init_host https://review.opendev.org/c/openstack/nova/+/977037 | |
| 09:47:10 | opendevreview | Ilia Baikov proposed openstack/nova master: compute: Pre-load flavor and system_metadata in init_host https://review.opendev.org/c/openstack/nova/+/977037 | |
| 09:52:38 | opendevreview | Ilia Baikov proposed openstack/nova master: compute: Pre-load flavor and system_metadata in init_host https://review.opendev.org/c/openstack/nova/+/977037 | |
| 09:53:22 | opendevreview | Ilia Baikov proposed openstack/nova master: compute: Pre-load flavor and system_metadata in init_host https://review.opendev.org/c/openstack/nova/+/977037 | |
| 10:32:53 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor memory encryption trait logic for extensibility https://review.opendev.org/c/openstack/nova/+/967971 | |
| 10:32:53 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: stop using _get_mem_encryption_config() for SEV checks https://review.opendev.org/c/openstack/nova/+/967970 | |
| 10:32:54 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973 | |
| 10:32:54 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972 | |
| 10:32:55 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | |
| 10:32:55 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | |
| 11:59:45 | nicolairuckel | oh, now even more jobs are failing | |
| 15:16:33 | stephenfin | Uggla: Did you just update https://blueprints.launchpad.net/nova/+spec/remove-os-volumes-boot-api? If so (a) your date is wrong and (b) it's all merged | |
| 15:16:58 | stephenfin | Uggla: https://review.opendev.org/c/openstack/nova/+/958864 | |
| 15:17:11 | stephenfin | I lost the topic during a rebase, clearly | |
| 15:18:19 | Uggla | stephenfin, yet updating the status. I have just realized I copy/paste a wrong comment. | |
| 15:24:14 | opendevreview | ribaudr proposed openstack/nova-specs master: Move Gazpacho implemented specs https://review.opendev.org/c/openstack/nova-specs/+/979283 | |
| 15:29:08 | nicolairuckel | frickler: Thanks for triggering another recheck. One of the tox jobs is still failing though: https://zuul.opendev.org/t/openstack/build/59c9b161b7334605a7ced566038547d2 Or do you think that may be because of my changes? | |
| 15:42:27 | stephenfin | nicolairuckel: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/2TF4CXQUCP4Y24PAKZQGM2D5BONL5Z34/ | |
| 15:58:03 | frickler | ah, why can't all openstack-tox-* jobs inherit from openstack-tox? *sigh* (I know why they don't, but that makes this pinning task tedious) | |
| 16:08:35 | opendevreview | ribaudr proposed openstack/nova master: DNM: Update min support for Hibiscus https://review.opendev.org/c/openstack/nova/+/979301 | |
| 16:28:00 | cardoe | Uggla: https://review.opendev.org/c/openstack/nova-specs/+/471815 is the spec that I've been trying to land with the implementation. I was told previously it was too late for 2026.1. This is the one that's had an implementation since 2024.x | |
| 16:28:14 | cardoe | sean-k-mooney: ^ that's the one we've talked about as well | |
| 16:34:50 | Uggla | cardoe, sorry but unless if I'm wrong this spec was not reproposed for 2026.1 and yes it is too late now. | |
| 16:35:31 | dansmith | Uggla: https://review.opendev.org/c/openstack/nova-specs/+/471815/11 | |
| 16:36:09 | sean-k-mooney | cardoe: oh the metadta one | |
| 16:36:26 | sean-k-mooney | cardoe: ya im still supprotive of actully geting that upstream | |
| 16:36:29 | dansmith | or maybe you mean wasn't tracked as such somewhere? I know @cardoe has been consistently harping on it so I don't think we can claim it was not proposed :) | |
| 16:37:03 | Uggla | cardoe, but I see this is a proposal for 2026.2 and I'll try to take care of it to land in 2026.2. | |
| 16:37:25 | sean-k-mooney | it was propsoed for the last few cycles | |
| 16:37:44 | sean-k-mooney | it just dint get reviewed beofre spec freeze | |