| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-04-22 | |||
| 16:12:51 | Uggla | gibi, I like your mindset ! :) | |
| 16:13:00 | elodilles | btw, i've prepared nova stable releases for dalmatian and caracal as well | |
| 16:13:16 | elodilles | to not leave everything till the end o:) | |
| 16:13:35 | elodilles | nova: Release 2024.1 Caracal 29.2.1 https://review.opendev.org/c/openstack/releases/+/947846 | |
| 16:13:45 | gibi | early upgrade opportunities :) | |
| 16:13:49 | elodilles | nova: Release 2024.2 Dalmatian 30.0.1 https://review.opendev.org/c/openstack/releases/+/947847 | |
| 16:14:05 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:14:14 | elodilles | please add here if you find any gate issue ^^^ | |
| 16:14:25 | elodilles | and that's all about stable from me for now | |
| 16:14:32 | elodilles | Uggla: back to you | |
| 16:14:40 | Uggla | thx elodilles ! | |
| 16:14:44 | elodilles | np | |
| 16:15:16 | Uggla | #topic Gibi's news about eventlet removal | |
| 16:15:25 | Uggla | #link Series: https://gibizer.github.io/categories/eventlet/ | |
| 16:15:31 | Uggla | #link reminder patches to review: https://review.opendev.org/q/topic:%22eventlet-removal%22+project:openstack/nova | |
| 16:15:49 | Uggla | gibi, anything new you want to share ? | |
| 16:16:06 | gibi | nope, you shared all what I had :) | |
| 16:16:12 | bauzas | as I said, I can help for reviewing the series | |
| 16:16:27 | gibi | any help is appreciated :) | |
| 16:16:36 | bauzas | cool | |
| 16:16:54 | Uggla | I know sean-k-mooney already reviewed some of them. | |
| 16:17:22 | Uggla | Having someone else would be great. | |
| 16:17:33 | sean-k-mooney | some yes melwitt looked at a couple too | |
| 16:17:40 | sean-k-mooney | but ya more the merrier | |
| 16:19:00 | Uggla | ok moving on to next topic | |
| 16:19:04 | Uggla | #topic Bug scrubbing | |
| 16:20:07 | Uggla | So I wanted to clean up a bit the new bugs. But I didn't have a chance to to it yet. Anyway I have selected 5 new bugs that looks properly defined. | |
| 16:20:33 | Uggla | So first one : https://bugs.launchpad.net/nova/+bug/2104255 | |
| 16:22:08 | Uggla | So my expected outcome would be to know if we think it is a valid bug or not. If it is incomplete what to ask. | |
| 16:22:56 | sean-k-mooney | its valid. i looked at it breifly and chated about it on irc | |
| 16:23:00 | bauzas | Seems a caching issue | |
| 16:23:08 | bauzas | so yeah valid | |
| 16:23:20 | sean-k-mooney | tl;dr if the nova-comptue agent is started when the vf is attached to the vm | |
| 16:23:28 | sean-k-mooney | we cant get the network capablities | |
| 16:23:42 | sean-k-mooney | and we cache the vf info on start up in both nova and libvirt | |
| 16:23:59 | sean-k-mooney | libvirt invalidates its cache based on udev events | |
| 16:24:12 | sean-k-mooney | i.e. when the vf is returned to the host | |
| 16:24:32 | sean-k-mooney | nova does nto invlaidate its cache so that part of the problem | |
| 16:24:35 | Uggla | ok cool do not worry about settings the bug fields I'll do that later after the call | |
| 16:24:40 | sean-k-mooney | lets mark it valid and medium | |
| 16:24:46 | Uggla | great | |
| 16:24:49 | sean-k-mooney | and we can decied how to fix it later | |
| 16:24:51 | Uggla | next one: | |
| 16:25:13 | Uggla | https://bugs.launchpad.net/nova/+bug/2105987 | |
| 16:26:18 | sean-k-mooney | so melwitt has a patch that might fix this indirectly | |
| 16:26:54 | sean-k-mooney | gibi: do you know if we merged the one to auto discover the config options and use the sdk to get the limits? | |
| 16:27:07 | gibi | sean-k-mooney: not top of my head | |
| 16:27:12 | sean-k-mooney | ack | |
| 16:27:20 | gibi | but the bug above links to a separate oslo.limit fix | |
| 16:27:24 | sean-k-mooney | so if this config option is not being repected in nova today | |
| 16:27:33 | sean-k-mooney | then its valid but we need to confirm that | |
| 16:27:35 | gibi | so I'm wondering if just using the latest oslo.limits fixes it for nova | |
| 16:27:56 | sean-k-mooney | ya i suspect that might be hte case | |
| 16:28:07 | sean-k-mooney | although im a bit confused | |
| 16:28:14 | sean-k-mooney | because the also have endpoint_interface | |
| 16:28:34 | sean-k-mooney | which i tought was ment to do the same thing as the new filed they just added | |
| 16:28:37 | sean-k-mooney | https://review.opendev.org/c/openstack/oslo.limit/+/946128/4/oslo_limit/opts.py | |
| 16:29:01 | sean-k-mooney | maybe we should ask if they set endpoint_interface=internal | |
| 16:29:12 | sean-k-mooney | in the bug and come back to this | |
| 16:29:32 | sean-k-mooney | ill go ask that | |
| 16:30:22 | Uggla | ok so we can set it to incomplete and then review it when it will be back in new. | |
| 16:31:35 | sean-k-mooney | tkajinam: sicne you wrote https://review.opendev.org/c/openstack/oslo.limit/+/946128 you might be able to add some context to https://bugs.launchpad.net/nova/+bug/2105987 | |
| 16:31:58 | sean-k-mooney | Uggla: for what its worht we configure our dwonstream installer to use internal too | |
| 16:32:09 | sean-k-mooney | so im not entirly sure why the oslo change is requried | |
| 16:32:14 | sean-k-mooney | but we can move on | |
| 16:33:10 | Uggla | ok next one: https://bugs.launchpad.net/nova/+bug/2106073 this one was opened by Mohammed Naser, corfirmed on Ironic. And I'm pretty sure Mohammed proposed a fix for it. | |
| 16:34:54 | Uggla | btw I have just noticed sean-k-mooney commented on it. | |
| 16:35:39 | sean-k-mooney | ya so this is unfixable in nova without rewriting parts of the ironic deriver | |
| 16:36:19 | sean-k-mooney | tl;dr ironic is modifying port bidinges, vnic typs and other atributes out of band of nova | |
| 16:36:51 | sean-k-mooney | that means that the info we provide in teh configdrive string can never be correct becuase ironic changes things in neutron that its not allowed too after we call provision | |
| 16:37:00 | Uggla | ok but that sounds a valid bug despite we rely on Ironic to fix it ? | |
| 16:37:20 | sean-k-mooney | so if itgs going to do that it also need ot update the config drive info it has | |
| 16:37:29 | sean-k-mooney | ya its somewhat valid to fix in ironic | |
| 16:37:47 | sean-k-mooney | again they are modifying neutron ports in a way that only valid wehn using ironic without nova | |
| 16:37:58 | sean-k-mooney | that the root of the issue. | |
| 16:38:12 | sean-k-mooney | ironic port groups only exixits in the ironic api | |
| 16:38:18 | sean-k-mooney | they are not modled in nova or neutron | |
| 16:38:33 | sean-k-mooney | so there is no portable way to express nic bonds ectra today | |
| 16:39:05 | Uggla | should we set it as "won't fix" on our side ? | |
| 16:39:10 | sean-k-mooney | i would proably mark the nova sid as cant fix | |
| 16:39:13 | sean-k-mooney | wont fix is fine too | |
| 16:39:21 | sean-k-mooney | i think we have invalid? | |
| 16:39:37 | sean-k-mooney | not sure which is better | |
| 16:39:39 | Uggla | yes invalid is an option too | |
| 16:40:35 | sean-k-mooney | anywya the tl;dr is because ironic and the ironic virt driver are doing thign virt drivers are not allowed too it can only be "fixed" in ironic | |
| 16:40:59 | Uggla | I vote for invalid on our side. Explaing ^ any objection with that ? | |
| 16:41:48 | Uggla | 3... | |
| 16:42:01 | Uggla | 2... | |
| 16:42:20 | Uggla | 1... | |
| 16:42:35 | Uggla | ok let's do that. | |
| 16:43:25 | Uggla | next one: https://bugs.launchpad.net/nova/+bug/2106380 | |
| 16:44:14 | sean-k-mooney | that seam valid ish | |
| 16:44:39 | sean-k-mooney | if we delete a vm we should remove it form instance_group_member in some form | |
| 16:44:49 | sean-k-mooney | i suspect that wont happen until we archive it however | |
| 16:45:06 | sean-k-mooney | although we dont have shadow tables in the api db | |
| 16:45:21 | sean-k-mooney | so perhaps we should just delete it when the vm is deleted | |
| 16:46:01 | gibi | yeah it seems like we should remove the vm from instance_group_member during delete, but it is hard as it is in the api db while the vm is in the cell db | |
| 16:46:08 | sean-k-mooney | there is a seperate bug for the slownes due to the request spec | |
| 16:46:15 | sean-k-mooney | loading | |
| 16:46:24 | sean-k-mooney | so we can keep that out of scope | |