| opendevreview | yatin proposed openstack/neutron master: [DNM] Check migration ovn https://review.opendev.org/c/openstack/neutron/+/972820 | 04:44 |
|---|---|---|
| -opendevstatus- NOTICE: Zuul is up and running again and should report back to Gerrit successfully. Changes can also merge if there are no other failures, but we expect that publication jobs like docs and tarballs updates will not work currently. | 05:02 | |
| *** ykarel_ is now known as ykarel | 05:36 | |
| ykarel | haleyb, ack | 06:15 |
| opendevreview | Rodolfo Alonso proposed openstack/networking-bgpvpn master: Change test code to use project_id key https://review.opendev.org/c/openstack/networking-bgpvpn/+/972226 | 07:07 |
| opendevreview | Brian Haley proposed openstack/networking-bgpvpn master: Remove py312 jobs from check and gate queue https://review.opendev.org/c/openstack/networking-bgpvpn/+/972786 | 07:07 |
| opendevreview | Théo Van Gyzel proposed openstack/neutron master: Fixed: network object was not updated after calling the enable driver while configure DHCP for a network https://review.opendev.org/c/openstack/neutron/+/962323 | 10:27 |
| opendevreview | Daniel Failing proposed openstack/neutron master: Improve OVNGatewayLeastLoadedScheduler runtime https://review.opendev.org/c/openstack/neutron/+/967827 | 10:42 |
| theovg | lajoskatona haleyb Hey! Sorry for the bother but it looks like PEP8 didn't break during verification but did during gate tests... I fixed it real quick if you could re-approve the change it would be appreciated, thank you! https://review.opendev.org/c/openstack/neutron/+/962323 | 12:19 |
| lajoskatona | theovg: no problem, some changes happened around pep8 so perhaps you run into that | 12:35 |
| theovg | Thanks! :) | 12:35 |
| *** root is now known as Guest35490 | 13:55 | |
| mlavalle | haleyb: are we meeting today? | 14:00 |
| haleyb | mlavalle: yes, just slow getting to desk | 14:00 |
| haleyb | #startmeeting neutron_drivers | 14:01 |
| opendevmeet | Meeting started Fri Jan 9 14:01:29 2026 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:01 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh | 14:01 |
| ralonsoh | hello | 14:01 |
| mtomaska | o/ | 14:01 |
| mlavalle | \o | 14:01 |
| haleyb | hi everyone, happy Friday :) | 14:02 |
| haleyb | i see we have two agenda items | 14:02 |
| slaweq | o/ | 14:03 |
| haleyb | first is from ralonsoh regarding OVN live migration | 14:03 |
| ralonsoh | thanks | 14:03 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2069718 | 14:03 |
| ralonsoh | In a nuthsell: we have problems with the live migration | 14:03 |
| lajoskatona | o/ | 14:03 |
| ralonsoh | in loaded compute nodes, if the ovn-controller does not have time to setup the OF rules, there will be a network disruption | 14:04 |
| ralonsoh | the TAP device is created when the VM is unpaused | 14:04 |
| ralonsoh | so, sean-k-mooney is now implementing a patch in os-vif to pre-create the TAP device | 14:04 |
| ralonsoh | in that case, libvirt won't need to do it in the unpause command | 14:05 |
| ralonsoh | #link https://review.opendev.org/c/openstack/os-vif/+/971231 | 14:05 |
| ralonsoh | from Neutron, we would like this to be configurable | 14:05 |
| ralonsoh | #link https://review.opendev.org/c/openstack/neutron/+/972039 | 14:05 |
| haleyb | just to make sure we don't break something? | 14:05 |
| ralonsoh | ^^ this patch requires an extra patch in Nova to parse this new binding variable | 14:06 |
| ralonsoh | haleyb, yes, to make it false by default | 14:06 |
| ralonsoh | but if that works the best strategy will be to enable it by default, but first let's test it | 14:06 |
| ralonsoh | and the last part from Neutron: | 14:06 |
| ralonsoh | to be able to send the vif-plugged event when OVN adds the additional chassis to the port binding | 14:07 |
| ralonsoh | #link https://review.opendev.org/c/openstack/neutron/+/956910 | 14:07 |
| ralonsoh | ^^ this patch requires Nova compute/os-vif to pre-create this TAP device | 14:07 |
| ralonsoh | so basically this is what we are trying now | 14:07 |
| slaweq | ralonsoh if that will work, what's the point of having it configurable? Are there any downsides of enabling it? | 14:07 |
| mtomaska | ^ I was wondering about the same | 14:08 |
| ralonsoh | slaweq, just to enable by default the current behaviour | 14:08 |
| ralonsoh | there are other platforms (DPDK, HW offloaded) that are not tested | 14:08 |
| ralonsoh | and we don't know the behaviour | 14:08 |
| ralonsoh | that was just a heads-up of what is happening there | 14:10 |
| haleyb | is plan to merge this cycle? | 14:10 |
| ralonsoh | well, I would like that but Nova is also involved | 14:11 |
| slaweq | so maybe, instead of having new config knob we could try to test this new behavior on different platforms as much as we can and if there would be no "hard" conditions why it has to be done in old way on some of the platforms, then simply use new approach everywhere. If there will be some issues with it we can always treat it as a bug, no? | 14:11 |
| ralonsoh | I really would like to haver it this cycle | 14:11 |
| ralonsoh | slaweq, the idea is to initially test it locally in the CI | 14:11 |
| ralonsoh | it could be enable by default and wait for the bugs later | 14:12 |
| haleyb | i guess i tend to agree with slawek to maybe enable by default, since there will be a config option it can be disabled if an issue is found | 14:13 |
| slaweq | ok, we can do it in couple of steps: first have it configurable and maybe even enabled by default, but then remove the config option at some point if it will be working fine | 14:13 |
| ralonsoh | the config option is just a safeguard to avoid disruptions in other envs | 14:13 |
| ralonsoh | it can be enabled/disabled quickly | 14:14 |
| slaweq | if can be done quickly but it means that we need to maintain 2 different code paths just because in one of them there may be a bug :) | 14:14 |
| ralonsoh | ok, I'll talk to sean-k-mooney about this | 14:15 |
| slaweq | I think that if we will decide to go with config option, it should be temporary solution (safeguard) and final goal should be to switch to new solution and remove config option then | 14:15 |
| haleyb | right. i guess i see more downstream work if not enabled by default, just to enable it in two installers :) | 14:15 |
| haleyb | and if we want to enable by default i guess we should do this cycle in neutron, as it's a new option | 14:18 |
| lajoskatona | if we enable by default in neutron will that affect Nova also? | 14:18 |
| lajoskatona | even if nova work is not merged , or that is not possible< | 14:19 |
| lajoskatona | ? | 14:19 |
| haleyb | right, and without the os-vif code does the option do anything? i haven't looked at code yet | 14:19 |
| ralonsoh | not yet | 14:19 |
| ralonsoh | the os-vif patch makes the change unconditionally | 14:19 |
| ralonsoh | it was agreed to have this knob in Neutron and I commented that in the os-vif patch | 14:19 |
| sean-k-mooney | for hardware offload | 14:20 |
| sean-k-mooney | we don not use taps nor for dpdk | 14:20 |
| sean-k-mooney | so this would only be done for vanilla kernel ovs | 14:20 |
| sean-k-mooney | for hardware offloaded ovs we are adding the representor vf during plugging already | 14:21 |
| sean-k-mooney | so that shoudl not be impacted | 14:21 |
| sean-k-mooney | for vhos-user ovn need to be able to compute hte flows without the of-port bring assigned | 14:22 |
| ralonsoh | ^^ how is that?? | 14:22 |
| sean-k-mooney | fundementlly that is the reguression form ml2/ovs ot ml2/ovn | 14:22 |
| ralonsoh | we can talk later, maybe | 14:22 |
| sean-k-mooney | sure | 14:22 |
| ralonsoh | so basically the knob is necessary right now (I would need to change the patch only to include it in vanilla ovs porbinding ) | 14:23 |
| sean-k-mooney | the reason we need the knob is really for live migration in a mixed upgraded env | 14:24 |
| sean-k-mooney | so it can be intoduced as deprecated | 14:24 |
| sean-k-mooney | and dropped in 2026.2 | 14:24 |
| sean-k-mooney | well if nova raises it min os-vif version. we can dicusscus this more sperately if you like | 14:25 |
| slaweq | sean-k-mooney ++ that is what I was talking about, thx | 14:25 |
| slaweq | so we don't need to keep that knob forever | 14:26 |
| slaweq | thx | 14:26 |
| haleyb | so is there a nova patch as well? | 14:26 |
| sean-k-mooney | there will be when i write it | 14:26 |
| haleyb | :) | 14:26 |
| sean-k-mooney | im currently setting up a 2 node devstack to devleop and test htis | 14:26 |
| sean-k-mooney | the nova patch is tweakign the xml generation if the flag is set in the neutron vif binding:details field and passing the flag to os-vif | 14:27 |
| sean-k-mooney | so that shoudl be pretty simple | 14:27 |
| sean-k-mooney | i should have that ready in the next day or two. | 14:28 |
| haleyb | ok, should we vote on approving this for neutron? | 14:30 |
| haleyb | or are there other questions? | 14:30 |
| lajoskatona | no question from me | 14:31 |
| mlavalle | i'm ok with it | 14:31 |
| haleyb | my network blipped, thought i was disconnected for a second | 14:31 |
| haleyb | +1 from me | 14:32 |
| mlavalle | +1 | 14:32 |
| mlavalle | to formalizae my vote | 14:32 |
| slaweq | +1 | 14:32 |
| lajoskatona | +1 | 14:32 |
| ralonsoh | thank you all for your time, I hope this time we'll improve even more the live-migraiton | 14:32 |
| haleyb | i'll mark it approved, thanks for working on it ralonsoh and sean-k-mooney | 14:33 |
| haleyb | there was one other agenda item from mtomaska | 14:34 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2135228 | 14:34 |
| mtomaska | I added more details in comment#2 | 14:34 |
| mtomaska | but in a nutshell. This is more of a "debug tool". A user will be able to create a local port which will contain mirrored traffic from one or more VM ports on the same chassis | 14:35 |
| lajoskatona | I wrote in comment that what sounds interesting is the mirroring of offloaded traffic can be most interesting | 14:35 |
| mtomaska | I feel like this will be only useful on environments where you can not directly attach tcpdump to a vm port. I.e. OVN-DPDK | 14:36 |
| sean-k-mooney | you can do a tcp dump usin gthe ovs dpdk tooling | 14:37 |
| sean-k-mooney | they have a commnad for that | 14:37 |
| haleyb | ovs-tcpdump, but i don't know if it works for ovn dpdk? | 14:37 |
| slaweq | it sounds good for me. The only small comment I have is that maybe it should be allowed to admin user only by default because IIUC owner of the port (regular user) will not benefit from creating such mirror as will not have access to the compute node, right? | 14:38 |
| sean-k-mooney | well the toole work with dpdk ports in genreal i belive | 14:38 |
| mtomaska | @slaweq, good point | 14:38 |
| lajoskatona | +1 for admin user | 14:39 |
| mtomaska | is ovs-tcpdump available in default installation? | 14:39 |
| haleyb | it's typically in openvswitch-switch package | 14:40 |
| haleyb | it basically makes a clone of an OVS port so tcpdump can work | 14:40 |
| mtomaska | yes | 14:40 |
| sean-k-mooney | it was created specificly to allwo you to use ovs-dpdk with tcpdump yes | 14:41 |
| mtomaska | but if admin can use ovs-tcpdump and they prefer it, then maybe this RFE does not provide much value? | 14:41 |
| sean-k-mooney | ovn shoudl not really impact that as this is workign at the ovs level with that said i have not tested that | 14:41 |
| ralonsoh | mtomaska, I was going to ask this | 14:42 |
| ralonsoh | if you can provide extra functionalities, maybe that could be useful | 14:42 |
| sean-k-mooney | mtomaska: my main concer looking at it privly was that it woudl imply that the ports on the vswitch are exposed via the rest api | 14:42 |
| haleyb | i'm also not sure it can see dpdk traffic, would have to verify | 14:43 |
| sean-k-mooney | `openstack tap mirror create --port some_vm_port --name other-vm --directions BOTH --mirror-type local --local-mirror-port my-vm` | 14:43 |
| ralonsoh | haleyb, yes it does | 14:43 |
| haleyb | mtomaska: we use ovs-tcpdump in our internal clouds here | 14:43 |
| sean-k-mooney | so if it was not admin only user could do ^ | 14:43 |
| sean-k-mooney | for vms form other tenants | 14:43 |
| sean-k-mooney | i thinki mixed up --port and --name in that example but you get the point | 14:44 |
| mtomaska | Sean, we would implement some SRBAC to limit port mirror creation | 14:44 |
| mtomaska | no :) | 14:45 |
| sean-k-mooney | exposing the ablity to specify vswitch prot names is problematic | 14:45 |
| mtomaska | are you saying that someone would be able to "redirect" traffic from one vm to another? | 14:45 |
| sean-k-mooney | yes or monitor it | 14:45 |
| sean-k-mooney | i know that is what tap as a service is for | 14:46 |
| opendevreview | Eduardo Olivares proposed x/whitebox-neutron-tempest-plugin master: [multicast] Only use vlan_transparent option when really required https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/972899 | 14:46 |
| sean-k-mooney | but if you are exposing the actul vswich port names in the api | 14:46 |
| sean-k-mooney | that causes multi teancy problems | 14:46 |
| mtomaska | That is how "intrusion detection system" work, but for that we have remote port mirroring | 14:46 |
| mtomaska | no vswitch port will not be exposed in api | 14:47 |
| mtomaska | It would just create an interface directly in OVS (maybe using an agent) | 14:47 |
| sean-k-mooney | ok so i miss understood what -local-mirror-port and --port are | 14:47 |
| mtomaska | Disregard example :) See comment#2 | 14:48 |
| sean-k-mooney | ack | 14:49 |
| sean-k-mooney | ignore me then | 14:49 |
| lajoskatona | do we need perhaps spec to make clear all these questions for everybody? | 14:49 |
| mtomaska | But yes what would happen under the hood is something like this. ovs-vsctl add-port br-int destination_port -- set interface destination_port type=internal | 14:49 |
| mtomaska | but if we have ovs-tcpdump then I am questioning value of this RFE :) | 14:50 |
| haleyb | mtomaska: that was going to be my next question - is it basically doing what ovs-tcpdump does? | 14:50 |
| sean-k-mooney | did they ever fix teh performance impact of mirroring form a vhost-user prot to type=internal | 14:50 |
| mtomaska | I need to experiment with ovs-tcpdump | 14:51 |
| sean-k-mooney | all tx traffinc to a type internal port used to fall back to the ovs-vswichd main thread | 14:51 |
| * haleyb shrugs | 14:51 | |
| sean-k-mooney | well tx and rx | 14:51 |
| mtomaska | Yep there is performance impact for sure, thats why this is for debug only | 14:51 |
| sean-k-mooney | that used to significally impact the performace of the PMDs | 14:51 |
| mlavalle | yeah, I think that at this point in time experimnting with ovs-tcpdump seems that the sensible next step | 14:51 |
| mtomaska | I agree | 14:52 |
| lajoskatona | +1 | 14:52 |
| mtomaska | so maybe this RFE is incomplete | 14:52 |
| mlavalle | that way we can decide if the RFE is needed | 14:52 |
| haleyb | mtomaska: yes, see if it does what you need and we can go from there | 14:53 |
| mtomaska | it is not for me personally :) | 14:53 |
| mtomaska | but end customers. But yes, let me work on it bit more | 14:54 |
| mlavalle | oh, you don't do this for fun? | 14:54 |
| mtomaska | and I can bring it up next week | 14:54 |
| ralonsoh | mtomaska, thanks! | 14:54 |
| mtomaska | yes I like to mirror packets to my TV and watch in evenings | 14:54 |
| lajoskatona | thanks | 14:54 |
| haleyb | mtomaska: like the matrix | 14:54 |
| ralonsoh | in any case, a document about using ovs-tcpdump would be also a good output | 14:54 |
| mtomaska | thank you for the input | 14:55 |
| slaweq | mtomaska that's weird hobby :P | 14:55 |
| mtomaska | ACK | 14:55 |
| haleyb | ok, we are about out of time, are there any other topics to discuss? | 14:56 |
| mtomaska | ralonsoh: I have a doc already maybe I just need to make it public | 14:56 |
| mlavalle | not from me | 14:56 |
| mtomaska | all from me | 14:56 |
| lajoskatona | nothing from me | 14:56 |
| haleyb | ok, thanks for attending everyone and have a nice weekend! | 14:56 |
| haleyb | #endmeeting | 14:56 |
| opendevmeet | Meeting ended Fri Jan 9 14:56:57 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:56 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-09-14.01.html | 14:56 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-09-14.01.txt | 14:56 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-09-14.01.log.html | 14:56 |
| mlavalle | \o | 14:57 |
| ralonsoh | bye! | 14:57 |
| slaweq | have a nice one and see you | 14:57 |
| slaweq | o/ | 14:57 |
| mtomaska | o/ | 14:57 |
| lajoskatona | o/ | 14:57 |
| opendevreview | Bodo Petermann proposed openstack/os-vif master: Fixed bridge name when per_port_bridge is used https://review.opendev.org/c/openstack/os-vif/+/966410 | 15:15 |
| sean-k-mooney | ralonsoh: does https://paste.opendev.org/show/bMep54CV84Hrrhm5kWxp/ looks familar to you? devstack for me is failing with that | 15:52 |
| ralonsoh | sean-k-mooney, yes, one sec | 15:54 |
| ralonsoh | is that stable/2025.1? | 15:54 |
| sean-k-mooney | im also seeing error related ot ovn hashrigns in perodics | 15:54 |
| sean-k-mooney | not sure if that is related | 15:55 |
| ralonsoh | yes, it could be | 15:55 |
| ralonsoh | sean-k-mooney, what version is that? | 15:55 |
| sean-k-mooney | sqlalchemy.exc.ProgrammingError: (pymysql.err.ProgrammingError) (1146, "Table 'neutron.ovn_hash_ring' doesn't exist") | 15:55 |
| sean-k-mooney | master | 15:55 |
| sean-k-mooney | on debian 13 | 15:55 |
| sean-k-mooney | specifically 644d2b767df84e46a4df6b1b8f8725452dcda796 | 15:56 |
| sean-k-mooney | this is the vm i started setting up yesterday | 15:56 |
| ralonsoh | sean-k-mooney, what do you have in mechanism_drivers? | 15:57 |
| ralonsoh | in the ml2_plugin.ini file | 15:57 |
| sean-k-mooney | https://paste.opendev.org/show/blassOEdIr28ZeSG96T0/ | 15:57 |
| sean-k-mooney | i dont have any neutron related optio ndefien din my local.conf | 15:58 |
| sean-k-mooney | but ill check | 15:58 |
| sean-k-mooney | [ml2] | 15:59 |
| sean-k-mooney | tenant_network_types = geneve | 15:59 |
| sean-k-mooney | extension_drivers = port_security,qos | 15:59 |
| sean-k-mooney | type_drivers = local,flat,vlan,geneve | 15:59 |
| sean-k-mooney | overlay_ip_version = 4 | 15:59 |
| sean-k-mooney | mechanism_drivers = ovn | 15:59 |
| sean-k-mooney | so that all look normal | 15:59 |
| ralonsoh | and the ranges? because this error means you don't have enough tags (vlan, vxlan, geneve) | 16:00 |
| ralonsoh | is that error happening during the boot? | 16:00 |
| ralonsoh | or any specific command? | 16:00 |
| sean-k-mooney | the error is preventign devstack form completing | 16:01 |
| ralonsoh | well, this is while creating a network | 16:01 |
| sean-k-mooney | but ya the ranges seam to be broken | 16:01 |
| sean-k-mooney | actully no | 16:01 |
| ralonsoh | yeah, most probably during the public network creation | 16:01 |
| sean-k-mooney | vlan is broken | 16:01 |
| ralonsoh | can you pass me the whole ml2_plugin file? | 16:02 |
| ralonsoh | in private | 16:02 |
| sean-k-mooney | https://paste.opendev.org/show/bUGtHnI7Xesy8bniqQVW/ | 16:02 |
| sean-k-mooney | sure one sec | 16:02 |
| sean-k-mooney | https://termbin.com/iin2d | 16:02 |
| sean-k-mooney | the public network shoudl be of type flat | 16:03 |
| sean-k-mooney | and then the tenatn network shoudl be geneve | 16:03 |
| sean-k-mooney | by deault in openstack any way | 16:03 |
| sean-k-mooney | s/openstack/devstack/ | 16:03 |
| ralonsoh | yes, I see nothing wrong there | 16:03 |
| sean-k-mooney | there is not rant defiend for vlan network which will break but we shoudl not be useing htem by default | 16:04 |
| ralonsoh | in not range defined, that means you can use all vlan tags | 16:05 |
| sean-k-mooney | oh really didnt know htat | 16:05 |
| sean-k-mooney | https://termbin.com/e8sb that is my actul devstack log | 16:06 |
| sean-k-mooney | oh no its truncated | 16:06 |
| sean-k-mooney | https://paste.opendev.org/show/boTzCM8kagCRi2I6b5mU/ | 16:07 |
| sean-k-mooney | that waqs the reported error | 16:07 |
| sean-k-mooney | so its creating the private network | 16:07 |
| sean-k-mooney | which shoudl be geneve | 16:07 |
| ralonsoh | sean-k-mooney, ok maybe there could be a race condition (maybe) | 16:09 |
| ralonsoh | there is one single API initializing the segment ranges | 16:09 |
| ralonsoh | and because of this: | 16:10 |
| ralonsoh | [ml2_type_geneve] | 16:10 |
| ralonsoh | vni_ranges = 1:65536 | 16:10 |
| ralonsoh | you are creating 65K registers | 16:10 |
| ralonsoh | try reducing that to 1:1000 | 16:10 |
| opendevreview | Merged openstack/neutron master: Cleanup stale DHCP ports not bound to host https://review.opendev.org/c/openstack/neutron/+/968770 | 16:10 |
| sean-k-mooney | ok but im just using the defaults so im not sure why this woudl have broken. | 16:11 |
| sean-k-mooney | select count(*) from ml2_geneve_allocations; return 0 | 16:11 |
| ralonsoh | so that's a problem | 16:12 |
| sean-k-mooney | ya i wonder if its related to the other db issue whre teh tabel was not found | 16:12 |
| ykarel | sean-k-mooney, i recall seeing that but when did multiple stack.sh and some improper cleanup | 16:13 |
| ykarel | you seen in clean/first stack.sh? | 16:14 |
| ralonsoh | sean-k-mooney, can I have access to this VM? | 16:14 |
| sean-k-mooney | ykarel: i ran clan and stacked again before i hit this | 16:14 |
| sean-k-mooney | ralonsoh: sure i shoudl be able to give you access | 16:15 |
| ykarel | if not it could be same issue, and unstack.sh ; stack.sh should help. also recently came to attention there is some issue with unstack, so if you see process running even after unstack.sh then thats another issue | 16:15 |
| ralonsoh | I wasn't aware of this, good to know | 16:15 |
| ykarel | in that case have to manually clean those process or reboot until that's fixed | 16:15 |
| sean-k-mooney | ykarel: ya so unstack and stack shoudl be enough without clean | 16:15 |
| sean-k-mooney | if you need to clean there is a bug in neutron or devstack | 16:15 |
| ykarel | sean-k-mooney, i mean bug with unstack | 16:16 |
| ykarel | so after unstack if you see neutron process running then thats the bug i am referring, recently gthiemon1e mentioned about it | 16:16 |
| sean-k-mooney | so i havent checked if ther are any neutron process left after an unstack but i can do that seperatly. | 16:16 |
| sean-k-mooney | ykarel: that could be a regrssion with the split out of q-svc into neutron-api ectra | 16:17 |
| ykarel | yeap | 16:17 |
| sean-k-mooney | ralonsoh: do you have ipv6? if not i can set up a port forwad for you but if you like i can try replicating this on my other vm first and let you knwo if its repoducable | 16:17 |
| ralonsoh | sean-k-mooney, no, my internet provider gives me only ipv4 | 16:18 |
| sean-k-mooney | ack ill need to do a prot forward then or maybe tmate | 16:19 |
| ralonsoh | sean-k-mooney, once you stopped everything and stack again, check the ml2_geneve_allocations; | 16:19 |
| sean-k-mooney | let me kick of the same install on the other vm whihc is clean first and see if it repoduces | 16:19 |
| sean-k-mooney | is neutron testign with py 3.13 and or debian 13 by the way just ruling out that that is the issue | 16:21 |
| ykarel | atleast that not seen with ci jobs running with ovn and python3.13 so high chance not related to that | 16:24 |
| ykarel | i think fresh vm shouldn't see it but let's see | 16:24 |
| sean-k-mooney | ack i was debating replciating this on noble i can trivally create vms with that instead. | 16:24 |
| sean-k-mooney | i will let ye know if it repoduces | 16:25 |
| sean-k-mooney | if it does not ill unstack and see what if any service are left behind on the broken node | 16:25 |
| ykarel | +1 | 16:25 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == Detach the stdout and stderr after killing a external process https://review.opendev.org/c/openstack/neutron/+/972538 | 16:38 |
| sean-k-mooney | ralonsoh: while that is running https://review.opendev.org/c/openstack/os-vif/+/966410 fixes a bug with the per-port-bridge option which is the experimental temporty workaround | 16:45 |
| ralonsoh | sean-k-mooney, let me review that patch now | 16:45 |
| sean-k-mooney | no rush just mentioning it since ist realted ot the live migration topic | 16:45 |
| ralonsoh | sean-k-mooney, right, we call `_create_vif_port` with bridge in this case, that is pbXXX | 16:48 |
| ralonsoh | we should not use always vif.network.bridge but L208 | 16:49 |
| sean-k-mooney | right so the problem is the port exist check | 16:52 |
| sean-k-mooney | always used vif.network.bride | 16:52 |
| ralonsoh | in general, and checking the FT test, I think the patch is correct | 16:53 |
| sean-k-mooney | so we were missign the logic from https://review.opendev.org/c/openstack/os-vif/+/966410/4/vif_plug_ovs/ovs.py#208 | 16:53 |
| sean-k-mooney | to take the per port overried when needed | 16:54 |
| sean-k-mooney | the bug is kind of sbutle https://bugs.launchpad.net/os-vif/+bug/2133225 | 16:55 |
| sean-k-mooney | it all work fine once. | 16:55 |
| sean-k-mooney | i dont think we are currently testign with per_port_bridge in ci but even if we were we dont do agent restarts in ci | 16:55 |
| sean-k-mooney | they added coverage for thsi in teh functional test explcitly | 16:56 |
| sean-k-mooney | https://review.opendev.org/c/openstack/os-vif/+/966410/4/vif_plug_ovs/tests/functional/test_plugin.py#224 | 16:56 |
| sean-k-mooney | by calling plug again | 16:56 |
| ralonsoh | that should be idemponent, right? | 16:57 |
| sean-k-mooney | yep | 16:57 |
| sean-k-mooney | becuase the exist check was using teh wrong bride it was assuming that this was the first time the prot was added | 16:57 |
| sean-k-mooney | which ment we tried to creat the qos porfile again in the ovsdb | 16:57 |
| sean-k-mooney | on one hand its a valid thing to backport on the other hand im not sure that folks really use that config option in production | 16:59 |
| sean-k-mooney | as you are aware that was my intiall attempt to fix the live migration downtime before ovn supprot multipel logical switch ports | 17:01 |
| sean-k-mooney | https://github.com/openstack/os-vif/commit/b837c1a74f37191692a820711e431a75516a4abf | 17:01 |
| ralonsoh | yes, I remember that | 17:01 |
| sean-k-mooney | i never removed the experimatl part when we reaisied it wold not install the flows without the chase table entry | 17:02 |
| ralonsoh | I'll push on monday morning an update of the os_vif_tap_creation patch | 17:02 |
| ralonsoh | just only for vanilla ovs and marked for removal | 17:02 |
| sean-k-mooney | ack. | 17:04 |
| opendevreview | Brian Haley proposed openstack/neutron-lib master: Use py313 for all neutron-lib jobs https://review.opendev.org/c/openstack/neutron-lib/+/972735 | 17:21 |
| sean-k-mooney | ralonsoh: ykarel so ya unstacking is not stopping any fo the neutron- devstack services https://termbin.com/vs1f | 18:05 |
| sean-k-mooney | so that is a bug in devstack | 18:06 |
| ralonsoh | q- and neutron- should be the same | 18:06 |
| sean-k-mooney | clean works but that should not be required | 18:06 |
| ralonsoh | I'll check that on Monday and I'll open a bug | 18:06 |
| sean-k-mooney | well apprently not any more | 18:06 |
| ralonsoh | sorry, I'm disconnecting now, is quite late for me | 18:07 |
| ralonsoh | see you!! | 18:07 |
| sean-k-mooney | https://github.com/openstack/devstack/blob/master/unstack.sh#L161-L164 shoudl have cleaned it up | 18:07 |
| sean-k-mooney | and now worries o/ | 18:07 |
| sean-k-mooney | *no worries | 18:07 |
| sean-k-mooney | i need to dig more but i think the issue is the neutron-* service are never populated in the ENABLED_SERVICES dict | 18:27 |
| sean-k-mooney | the bug is here https://github.com/openstack/devstack/blob/master/lib/neutron#L609-L650 | 18:46 |
| sean-k-mooney | we are enabling the service in start_neutron_service_and_check | 18:46 |
| sean-k-mooney | i.e. addign them to the enabeld service dict | 18:46 |
| sean-k-mooney | that is incorrect that function wont be run in the unstack path | 18:46 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: func: Remove MySQL test case from OVN base class https://review.opendev.org/c/openstack/neutron/+/971472 | 18:47 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: func: Generate SQL file with schema https://review.opendev.org/c/openstack/neutron/+/972961 | 18:47 |
| sean-k-mooney | so we need to factor out the extnetion of the ENABLED_SERVICES dict into a seperate function that is involed in both code paths so we have the same list | 18:47 |
| sean-k-mooney | in general we shoudl minims calling enable_service in devstack itself although there are some valid cases but where we do call it we have to ensure its decupled form the logic ot actilly start the service | 18:49 |
| sean-k-mooney | ralonsoh: https://review.opendev.org/c/openstack/devstack/+/972963 fixes unstack but i need to confirm i didnt break stacking | 19:07 |
| sean-k-mooney | ok stakcing works and with that change applied to clean up the stales service when i unstacked | 19:55 |
| opendevreview | Merged openstack/networking-bgpvpn master: Change test code to use project_id key https://review.opendev.org/c/openstack/networking-bgpvpn/+/972226 | 20:51 |
| opendevreview | Brian Haley proposed openstack/neutron master: Change agent and Ipam code to use project_id https://review.opendev.org/c/openstack/neutron/+/972589 | 22:31 |
| opendevreview | Brian Haley proposed openstack/neutron master: Use project_id key in port plugin code https://review.opendev.org/c/openstack/neutron/+/972982 | 22:31 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: func: Do not teardown DB if not dirty https://review.opendev.org/c/openstack/neutron/+/972985 | 23:41 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: DNM: Trigger functional tests https://review.opendev.org/c/openstack/neutron/+/972986 | 23:51 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!