| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-19 | |||
| 21:52:57 | opendevreview | Dmitriy Chubinidze proposed openstack/nova master: docs: mention q35 machine type for UEFI guests https://review.opendev.org/c/openstack/nova/+/981413 | |
| 21:59:53 | opendevreview | Dmitriy Chubinidze proposed openstack/nova master: docs: mention q35 machine type for UEFI guests https://review.opendev.org/c/openstack/nova/+/981413 | |
| #openstack-nova - 2026-03-20 | |||
| 10:25:35 | opendevreview | ribaudr proposed openstack/nova master: Fix NUMA cell sorting for non-PCI VMs with pack strategy https://review.opendev.org/c/openstack/nova/+/978954 | |
| 10:25:35 | opendevreview | ribaudr proposed openstack/nova master: Reproduce bug #2144660: NUMA cell sorting bug for non-PCI VMs https://review.opendev.org/c/openstack/nova/+/978885 | |
| 11:05:05 | Uggla | sean-k-mooney, dansmith, I have answered comments ^ so if you can have a new review run. It will be great. | |
| 11:28:01 | opendevreview | Dmitriy Chubinidze proposed openstack/nova master: docs: mention q35 machine type for UEFI guests https://review.opendev.org/c/openstack/nova/+/981413 | |
| 12:28:07 | sean-k-mooney | Uggla: im +2 on both of those now. if you need to respine a release not would be nice but its not required | |
| 13:20:40 | Uggla | sean-k-mooney, yes I will write a release as discussed yesterday. | |
| 13:21:20 | Uggla | sean-k-mooney I'll keep you posted when it is done. | |
| 13:21:49 | opendevreview | ribaudr proposed openstack/nova master: Fix error when multiple security group in a project with same name https://review.opendev.org/c/openstack/nova/+/970337 | |
| 13:22:45 | Uggla | sean-k-mooney I have just pushed an update of https://review.opendev.org/c/openstack/nova/+/970337. Tell me if I understand well what you wanted to achieve. | |
| 13:31:24 | sean-k-mooney | ack ill take a look after im off a call | |
| 13:31:54 | opendevreview | ribaudr proposed openstack/nova master: Fix NUMA cell sorting for non-PCI VMs with pack strategy https://review.opendev.org/c/openstack/nova/+/978954 | |
| 13:36:51 | Uggla | sean-k-mooney release notes added in ^ | |
| 13:53:52 | sean-k-mooney | +2 on the sorting series ill re review https://review.opendev.org/c/openstack/nova/+/970337/4 in a little more detail | |
| 13:54:31 | sean-k-mooney | i think you made the changes i asked for but it woudl also be nice to have a very short release note for the security group bug too | |
| 13:55:42 | sean-k-mooney | nova.tests.unit.api.openstack.compute.test_schemas.SchemaTest.test_schemas | |
| 13:56:05 | sean-k-mooney | seems to be hitting the per test timeout on slower nodes in the coverage job | |
| 13:56:20 | sean-k-mooney | i wonder if we shoudl tweak that in the tox.ini | |
| 13:59:28 | Uggla | sean-k-mooney ok for the release note. "seems to be hitting the per test timeout on slower nodes in the coverage job" how do you see that ? | |
| 14:13:44 | sean-k-mooney | i looked at the coverage job on the repoducer | |
| 14:14:05 | sean-k-mooney | the schema validation test timed out but i have seen that on one or two other patches i think | |
| 14:14:13 | sean-k-mooney | so https://zuul.opendev.org/t/openstack/build/b2e50d5600ce479ca7287a2ebae35e79 | |
| 14:14:41 | sean-k-mooney | File "/home/zuul/src/opendev.org/openstack/nova/.tox/cover/lib/python3.12/site-packages/fixtures/_fixtures/timeout.py", line 57, in signal_handler | |
| 14:14:43 | sean-k-mooney | raise TimeoutException() | |
| 14:14:45 | sean-k-mooney | fixtures._fixtures.timeout.TimeoutException | |
| 14:15:09 | sean-k-mooney | that isnet a job timeout its a test timeout all the other test pass and it passed in the non coverage jobs | |
| 14:15:31 | sean-k-mooney | the corevate profileing slows thigns down a bit so i think on a slow node it just take longer then the defautl test timeout | |
| 14:16:24 | sean-k-mooney | im not 100% sure that is the cause as i have not looked at it in detail | |
| 14:16:35 | sean-k-mooney | Uggla: its unrelated to your change | |
| 14:17:00 | sean-k-mooney | i just wanted to mention it before recheckign incase we are sing this in ohter patches as it could become a semi gate blocker if that is unstable | |
| 14:18:10 | Uggla | sean-k-mooney, oh ok. I guess we can keep an eye on it, and discuss in next upstream meeting. | |
| 14:20:27 | obre | Is there any chance that this bugfix gets merged before the G-release? https://review.opendev.org/c/openstack/nova/+/916409 (A bug making rebuild of a BFV-instance impossible) | |
| 14:21:44 | sean-k-mooney | obre: unless the bug was intoduced in this cycle no | |
| 14:22:02 | sean-k-mooney | we are past rc1 so rc2+ only incldue bugs that were intoduced in this release | |
| 14:22:17 | sean-k-mooney | that does not mean it cant be backproted and release reight after | |
| 14:25:39 | Uggla | obre I have included it in the bug review list | |
| 14:26:47 | opendevreview | ribaudr proposed openstack/nova master: Fix error when multiple security group in a project with same name https://review.opendev.org/c/openstack/nova/+/970337 | |
| 14:27:22 | sean-k-mooney | obre: its in merge conflict and the orginal autor is not working on it | |
| 14:27:38 | sean-k-mooney | so someone will have to fix that again i might get to it next week | |
| 14:28:03 | sean-k-mooney | but it need review form peopel other then me to prgoress | |
| 14:28:37 | sean-k-mooney | if i find time ill push an update later today | |
| 14:28:50 | Uggla | sean-k-mooney, what is your opinion on that one: https://bugs.launchpad.net/nova/+bug/2145010 to me it is more a feature request than bug. Do you share the same feeling ? | |
| 14:29:29 | sean-k-mooney | so the are raising a commont issue | |
| 14:29:46 | sean-k-mooney | they are correct that day 1 it shoudl have used both | |
| 14:29:49 | sean-k-mooney | os_distro="debian" | |
| 14:29:51 | sean-k-mooney | os_version="13" | |
| 14:30:07 | sean-k-mooney | but the spec defied that os_distro="debian13" woudl be required | |
| 14:30:14 | sean-k-mooney | i.e that only os_distro woudl be used | |
| 14:30:23 | sean-k-mooney | even though os_version exsited | |
| 14:30:32 | sean-k-mooney | so that is a breakign api change in my view | |
| 14:30:45 | sean-k-mooney | as it will chenat the behvior for exsitng images | |
| 14:31:18 | sean-k-mooney | so i woudl close it as invalid but im biased again that feature as i personlly want to remove the libosinfo functionality entrily | |
| 14:31:26 | sean-k-mooney | i belive it was a mistake to ever include it | |
| 14:31:53 | sean-k-mooney | becuase it does nto provdie stable bevhor across version as they assuem the domian will not be deleted and recreated and rely on that for stablity | |
| 14:32:24 | sean-k-mooney | nova deletes and recreates the domain all the time so if you sue the libosinfo fucntionaltiy you can get unexpected bhavior in nova when you do a package update | |
| 14:33:28 | sean-k-mooney | i partly mitigated that in the past i think but it still makes me uneasey so i woudl mark this opion and whishlist | |
| 14:33:56 | sean-k-mooney | i dont think it woudl be safe to turn this on by defautl (looking at both disto and version) without a flag to opt in | |
| 14:34:34 | sean-k-mooney | they are totally right to expect it to look at both its just not how it was implmeented unfortunetly | |
| 14:35:01 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/libvirt-hardware-policy-from-libosinfo.html | |
| 14:35:39 | sean-k-mooney | the spec actully say it use –property os_name=fedora21 but i woudl have to double check that | |
| 14:37:17 | sean-k-mooney | ya its usign os_name today https://github.com/openstack/nova/blob/master/nova/virt/osinfo.py#L93 | |
| 14:37:31 | sean-k-mooney | oh no os_disto https://github.com/openstack/nova/blob/master/nova/virt/osinfo.py#L136 | |
| 14:37:54 | sean-k-mooney | os_name is the vairable name | |
| 14:37:54 | Uggla | sean-k-mooney, that's fine I answered with "invalid" because based on what you have said above, clearly it is a behavior change so more a BP than a bug. | |
| 14:38:11 | sean-k-mooney | yep that fair | |
| 14:38:28 | sean-k-mooney | i think fi we ant to do the se need a new image proeprty to enabel using this functionlty | |
| 14:38:35 | sean-k-mooney | we coudl perhaps eventually change the defualt of that | |
| 14:39:00 | sean-k-mooney | but as a new feature it woudl have to be opt in i think for a release or two before we consider if it can be the default | |
| 14:39:48 | sean-k-mooney | by the way currently when you use this feature we only use it for 2 things | |
| 14:40:05 | sean-k-mooney | the hw_vif_model and hw_disk_bus defaults | |
| 14:40:42 | sean-k-mooney | if we were to use libosinfo there are many other thing it could express an opion on but we have moved toward usign libvirts defaults instead | |
| 14:40:49 | sean-k-mooney | our our own in code | |
| 14:41:24 | sean-k-mooney | we are not tellign libosinfo about the machine type we are suign for example or the architecure | |
| 14:41:44 | sean-k-mooney | so today it can provide sub optimal or invalide recomendation in some cases | |
| 14:42:20 | sean-k-mooney | the feature was never really updated after it was initally created so its somethign i discuage peopel from using | |
| 14:43:54 | sean-k-mooney | the last change was https://github.com/openstack/nova/commit/6be668e51992df53a4d871bea70bc738a9beacb8 to workaround a breakign change in libosinfo so i just see this as tech debt today | |
| 15:01:15 | bauzas | sean-k-mooney: do you have time for a question about https://review.opendev.org/c/openstack/nova/+/979999 ? | |
| 15:03:22 | bauzas | sean-k-mooney: tl;dr wasn't able to find any difference between the code and the fixtures, so I can't see any leak | |
| 15:14:58 | sean-k-mooney | bauzas: ack im not sure where the change in behvior is either. but i kown we were not ablt to propperly repoduce it in https://review.opendev.org/c/openstack/nova/+/914712 when we tried. we coudl only repoduce it in devstack | |
| 15:15:38 | bauzas | sean-k-mooney: I looked that we were providing the limits in the Selection object | |
| 15:15:47 | bauzas | that's why it works | |
| 15:16:08 | sean-k-mooney | right but i dont thnk we have that on the compute node right | |
| 15:16:34 | sean-k-mooney | only in the schduler so i asuem it was drop in the rpc? | |
| 15:18:01 | sean-k-mooney | bauzas: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2505 | |
| 15:18:20 | sean-k-mooney | build_and_run_instance accpate the limits object but im not sure if we pass it | |
| 15:18:25 | sean-k-mooney | and what it contains | |
| 15:18:26 | bauzas | we pass the limits | |
| 15:18:30 | bauzas | by it | |
| 15:19:02 | bauzas | of course, if we no longer have alternates, then we call back to the conductor and then we miss the limits | |
| 15:19:22 | bauzas | also, limits are not persisted so when you resize, you don't look at the network metadata | |
| 15:19:39 | sean-k-mooney | well yes because they can change on resize | |
| 15:20:00 | bauzas | so yeah, we should get the network metadata by the claim, but as I said, I can't reproduce the issue | |
| 15:20:01 | sean-k-mooney | they shoudl not be persited they shoudl be calcuatled on each create/resize/rebuild | |
| 15:20:05 | bauzas | correct | |
| 15:22:49 | sean-k-mooney | i can see if i can make some time to try and look into it next week im currently tryitn to wrap up some cybrog stuff for rc2 so i proably cant dig into it indetail today | |
| 15:23:13 | sean-k-mooney | bauzas: are you currently blocked or do you have enfor info to try workign on the fix? | |
| 15:23:39 | bauzas | I'll work on the fix | |
| 15:25:48 | sean-k-mooney | ack my best advice right now is try adding some LOG.debug statement like artom did https://review.opendev.org/c/openstack/nova/+/914712 | |
| 15:25:58 | sean-k-mooney | or even take over that patch | |