| 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 | 10:25 |
|---|---|---|
| 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 |
| Uggla | sean-k-mooney, dansmith, I have answered comments ^ so if you can have a new review run. It will be great. | 11:05 |
| opendevreview | Dmitriy Chubinidze proposed openstack/nova master: docs: mention q35 machine type for UEFI guests https://review.opendev.org/c/openstack/nova/+/981413 | 11:28 |
| 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 | 12:28 |
| Uggla | sean-k-mooney, yes I will write a release as discussed yesterday. | 13:20 |
| Uggla | sean-k-mooney I'll keep you posted when it is done. | 13:21 |
| 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:21 |
| 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:22 |
| sean-k-mooney | ack ill take a look after im off a call | 13:31 |
| 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:31 |
| Uggla | sean-k-mooney release notes added in ^ | 13:36 |
| 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:53 |
| 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:54 |
| sean-k-mooney | nova.tests.unit.api.openstack.compute.test_schemas.SchemaTest.test_schemas | 13:55 |
| sean-k-mooney | seems to be hitting the per test timeout on slower nodes in the coverage job | 13:56 |
| sean-k-mooney | i wonder if we shoudl tweak that in the tox.ini | 13:56 |
| 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 ? | 13:59 |
| sean-k-mooney | i looked at the coverage job on the repoducer | 14:13 |
| sean-k-mooney | the schema validation test timed out but i have seen that on one or two other patches i think | 14:14 |
| sean-k-mooney | so https://zuul.opendev.org/t/openstack/build/b2e50d5600ce479ca7287a2ebae35e79 | 14:14 |
| 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 |
| sean-k-mooney | raise TimeoutException() | 14:14 |
| sean-k-mooney | fixtures._fixtures.timeout.TimeoutException | 14:14 |
| 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 |
| 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:15 |
| sean-k-mooney | im not 100% sure that is the cause as i have not looked at it in detail | 14:16 |
| sean-k-mooney | Uggla: its unrelated to your change | 14:16 |
| 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:17 |
| Uggla | sean-k-mooney, oh ok. I guess we can keep an eye on it, and discuss in next upstream meeting. | 14:18 |
| 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:20 |
| sean-k-mooney | obre: unless the bug was intoduced in this cycle no | 14:21 |
| sean-k-mooney | we are past rc1 so rc2+ only incldue bugs that were intoduced in this release | 14:22 |
| sean-k-mooney | that does not mean it cant be backproted and release reight after | 14:22 |
| Uggla | obre I have included it in the bug review list | 14:25 |
| 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:26 |
| sean-k-mooney | obre: its in merge conflict and the orginal autor is not working on it | 14:27 |
| sean-k-mooney | so someone will have to fix that again i might get to it next week | 14:27 |
| sean-k-mooney | but it need review form peopel other then me to prgoress | 14:28 |
| sean-k-mooney | if i find time ill push an update later today | 14:28 |
| 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:28 |
| sean-k-mooney | so the are raising a commont issue | 14:29 |
| sean-k-mooney | they are correct that day 1 it shoudl have used both | 14:29 |
| sean-k-mooney | os_distro="debian" | 14:29 |
| sean-k-mooney | os_version="13" | 14:29 |
| sean-k-mooney | but the spec defied that os_distro="debian13" woudl be required | 14:30 |
| sean-k-mooney | i.e that only os_distro woudl be used | 14:30 |
| sean-k-mooney | even though os_version exsited | 14:30 |
| sean-k-mooney | so that is a breakign api change in my view | 14:30 |
| sean-k-mooney | as it will chenat the behvior for exsitng images | 14:30 |
| 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 |
| sean-k-mooney | i belive it was a mistake to ever include it | 14:31 |
| 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:31 |
| 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:32 |
| 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 |
| 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:33 |
| sean-k-mooney | they are totally right to expect it to look at both its just not how it was implmeented unfortunetly | 14:34 |
| sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/libvirt-hardware-policy-from-libosinfo.html | 14:35 |
| sean-k-mooney | the spec actully say it use –property os_name=fedora21 but i woudl have to double check that | 14:35 |
| sean-k-mooney | ya its usign os_name today https://github.com/openstack/nova/blob/master/nova/virt/osinfo.py#L93 | 14:37 |
| sean-k-mooney | oh no os_disto https://github.com/openstack/nova/blob/master/nova/virt/osinfo.py#L136 | 14:37 |
| 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:37 |
| sean-k-mooney | os_name is the vairable name | 14:37 |
| sean-k-mooney | yep that fair | 14:38 |
| sean-k-mooney | i think fi we ant to do the se need a new image proeprty to enabel using this functionlty | 14:38 |
| sean-k-mooney | we coudl perhaps eventually change the defualt of that | 14:38 |
| 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 |
| sean-k-mooney | by the way currently when you use this feature we only use it for 2 things | 14:39 |
| sean-k-mooney | the hw_vif_model and hw_disk_bus defaults | 14:40 |
| 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 |
| sean-k-mooney | our our own in code | 14:40 |
| sean-k-mooney | we are not tellign libosinfo about the machine type we are suign for example or the architecure | 14:41 |
| sean-k-mooney | so today it can provide sub optimal or invalide recomendation in some cases | 14:41 |
| sean-k-mooney | the feature was never really updated after it was initally created so its somethign i discuage peopel from using | 14:42 |
| 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 | 14:43 |
| bauzas | sean-k-mooney: do you have time for a question about https://review.opendev.org/c/openstack/nova/+/979999 ? | 15:01 |
| 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:03 |
| 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:14 |
| bauzas | sean-k-mooney: I looked that we were providing the limits in the Selection object | 15:15 |
| bauzas | that's why it works | 15:15 |
| sean-k-mooney | right but i dont thnk we have that on the compute node right | 15:16 |
| sean-k-mooney | only in the schduler so i asuem it was drop in the rpc? | 15:16 |
| sean-k-mooney | bauzas: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2505 | 15:18 |
| sean-k-mooney | build_and_run_instance accpate the limits object but im not sure if we pass it | 15:18 |
| sean-k-mooney | and what it contains | 15:18 |
| bauzas | we pass the limits | 15:18 |
| bauzas | by it | 15:18 |
| bauzas | of course, if we no longer have alternates, then we call back to the conductor and then we miss the limits | 15:19 |
| bauzas | also, limits are not persisted so when you resize, you don't look at the network metadata | 15:19 |
| sean-k-mooney | well yes because they can change on resize | 15:19 |
| bauzas | so yeah, we should get the network metadata by the claim, but as I said, I can't reproduce the issue | 15:20 |
| sean-k-mooney | they shoudl not be persited they shoudl be calcuatled on each create/resize/rebuild | 15:20 |
| bauzas | correct | 15:20 |
| 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:22 |
| sean-k-mooney | bauzas: are you currently blocked or do you have enfor info to try workign on the fix? | 15:23 |
| bauzas | I'll work on the fix | 15:23 |
| 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 |
| sean-k-mooney | or even take over that patch | 15:25 |
| sean-k-mooney | and see if you can repoduce in devstack | 15:26 |
| sean-k-mooney | we can hopefully use that info to fix the funtional tests or repoduce in a unit test later | 15:26 |
| opendevreview | ribaudr proposed openstack/nova master: Reproduce bug #2108974: keypairs lost during cross-cell resize https://review.opendev.org/c/openstack/nova/+/981557 | 17:33 |
| opendevreview | ribaudr proposed openstack/nova master: Fix keypairs lost during cross-cell resize https://review.opendev.org/c/openstack/nova/+/981558 | 17:33 |
| opendevreview | Merged openstack/nova master: Reproduce bug #2144660: NUMA cell sorting bug for non-PCI VMs https://review.opendev.org/c/openstack/nova/+/978885 | 20:42 |
| opendevreview | Merged openstack/nova master: Fix NUMA cell sorting for non-PCI VMs with pack strategy https://review.opendev.org/c/openstack/nova/+/978954 | 20:57 |
| opendevreview | Merged openstack/nova master: FUP Add HW_PCI_LIVE_MIGRATABLE trait to PCI resource providers https://review.opendev.org/c/openstack/nova/+/977310 | 21:52 |
| opendevreview | Merged openstack/nova master: Tidy up pci self.flags() calls in SR-IOV functional tests https://review.opendev.org/c/openstack/nova/+/978479 | 21:52 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!