| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-04-22 | |||
| 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 | |
| 16:47:26 | sean-k-mooney | so dansmith and i were wondering about a related topic. if you do not have api access from teh cell condutor and do local delete beacuse the conenction to the cell is down | |
| 16:47:42 | sean-k-mooney | will anything clean up the instnace mapping? | |
| 16:48:17 | sean-k-mooney | like to me this feels similar i feel like the instnace group membership is somethign we shoudl eb cleaning up once the instnace goes to delete in the cell db | |
| 16:48:22 | gibi | I think it would have the same problem that the VM delete happens in the cell and we don't have an up call | |
| 16:48:24 | sean-k-mooney | but i dont know if anythign will actully do it today | |
| 16:48:57 | sean-k-mooney | gibi: this kind of feels like something the supercondutor could do as a perodic | |
| 16:49:03 | gibi | so the only reliable way would be a periodic | |
| 16:49:04 | gibi | yepp | |
| 16:49:13 | sean-k-mooney | but i belive that would be the first such perodic in teh super conductor | |
| 16:49:21 | gibi | yeah, I think so | |
| 16:49:42 | gibi | not impossible to do just not a low hanging bugfiz | |
| 16:49:43 | gibi | x | |
| 16:49:50 | sean-k-mooney | Uggla: to summerise, this is valid, it proably need a new periodic and there are likely other cases like this that should be fixed | |
| 16:50:09 | Uggla | perfect. | |
| 16:50:49 | sean-k-mooney | i would also agree not a low hanging fuirt but perhaps low to medium imporantce | |
| 16:52:13 | Uggla | Latest one for this week: https://bugs.launchpad.net/nova/+bug/2106817 | |
| 16:55:58 | gibi | no stack trace so it is hard to tell | |
| 16:56:03 | sean-k-mooney | so neutron supproted adressless port long before nova did | |
| 16:56:18 | sean-k-mooney | sylvain added supprot for adressless port but i dont know if that in antelope? | |
| 16:56:54 | bauzas | bobcat iirc | |
| 16:57:05 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/yoga/implemented/boot-vm-with-unaddressed-port.html | |
| 16:57:06 | bauzas | or maybe antelope, can't remember this | |
| 16:57:09 | sean-k-mooney | it was actully yoga | |
| 16:57:14 | bauzas | ohoho | |
| 16:57:36 | sean-k-mooney | but i do know there are still some issue with metadta | |
| 16:58:21 | sean-k-mooney | so they are aslo using trunk ports | |
| 16:58:29 | sean-k-mooney | whic i dont know if that was tested as part of this | |
| 16:59:06 | sean-k-mooney | they are also doing this via heat | |
| 16:59:12 | sean-k-mooney | which is fun... | |
| 16:59:32 | Uggla | maybe we can ask for a reproducer. At least the procedure to reproduce it | |
| 16:59:36 | Uggla | without heat | |