| opendevreview | Rico Lin proposed openstack/neutron master: Fix ovn db sync with log resources https://review.opendev.org/c/openstack/neutron/+/948053 | 01:03 |
|---|---|---|
| opendevreview | Liushy proposed openstack/neutron master: [ovn]Allow multiple IPv6 ports on router from same network https://review.opendev.org/c/openstack/neutron/+/936931 | 03:04 |
| opendevreview | yatin proposed openstack/networking-bagpipe master: [DNM] Check tempest failure https://review.opendev.org/c/openstack/networking-bagpipe/+/948170 | 03:08 |
| opendevreview | liuyulong proposed openstack/neutron master: Adds unique constraint for network segment ranges https://review.opendev.org/c/openstack/neutron/+/947898 | 03:57 |
| opendevreview | Rico Lin proposed openstack/neutron master: Fix ovn db sync with log resources https://review.opendev.org/c/openstack/neutron/+/948053 | 05:29 |
| ykarel | tobias-urdin, hi when you get chance can you check/triage dynamic routing bug https://bugs.launchpad.net/neutron/+bug/2108985 ? | 07:48 |
| opendevreview | yatin proposed openstack/neutron master: [UT] Keep metadata disabled in no_dhcp_release6 check test https://review.opendev.org/c/openstack/neutron/+/948180 | 08:23 |
| slaweq | liushy hi, am I correct that you were working on the ovn driver for neutron-fwaas? If yes, do you maybe remember why it was implemented as "stateless" ACLs? | 08:43 |
| liushy | slaweq, because ovn-northd does not apply stateful ACLs for router ports by default: https://github.com/ovn-org/ovn/blob/9ca70580745e11e7b467feea91453a2f80e658d6/northd/northd.c#L6020 | 08:50 |
| tobias-urdin | ykarel: ack, just glancing at it looks valid, but dvr is a bit of a blackbox to me as i've never tried it | 08:51 |
| opendevreview | Vasyl Saienko proposed openstack/ovn-octavia-provider master: Prepare to handle ha_chassis_group for LRP https://review.opendev.org/c/openstack/ovn-octavia-provider/+/943243 | 09:02 |
| opendevreview | Merged openstack/neutron stable/2025.1: Return a HTTP404 message when the Metadata instance is not present https://review.opendev.org/c/openstack/neutron/+/947947 | 10:21 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Subnet filter by "router:external" needs to be changed to "external" https://review.opendev.org/c/openstack/neutron/+/948073 | 10:32 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: [FWaaS] Update icmp_reachability_test for OVN backend https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/947920 | 10:57 |
| frickler | ykarel: tobias-urdin: also zed is unmaintained, so likely my first question would be whether the issue can be reproduced with a maintained release. likely not much has changed on the n-d-r side, but maybe for DVR? (/me also doesn't use DVR nor BGP for IPv4) | 12:25 |
| ykarel | thx frickler tobias-urdin will ask for reproducibility in master or stable release | 13:03 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Initialize the network segment ranges only in first WSGI worker https://review.opendev.org/c/openstack/neutron/+/948200 | 13:49 |
| haleyb | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Apr 25 14:00:14 2025 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, haleyb, ralonsoh | 14:00 |
| slaweq | o/ | 14:00 |
| obondarev | o/ | 14:00 |
| ralonsoh | hello | 14:00 |
| yusufgungor_ | o/ | 14:00 |
| haleyb | hopefully one more driver will come, but we do have 4 so can get started | 14:01 |
| haleyb | slaweq: did you want to start with https://bugs.launchpad.net/neutron/+bug/2106816 ? it was on the agenda for a previous week | 14:02 |
| slaweq | sure | 14:02 |
| mlavalle | \o | 14:02 |
| slaweq | basically this is just an idea about improvement | 14:02 |
| slaweq | this is already available in ovn since some time | 14:02 |
| slaweq | so I was thinking on doing that in neutrn as new qos rule type | 14:03 |
| slaweq | of course if there will be no hard "no" for this idea I will do spec first as this will require new APIs, etc. | 14:04 |
| ralonsoh | just asking, what does this feature provides? | 14:05 |
| haleyb | the description in the OVN change makes it sound like limiting the number of things in a CT zone, but it's more at QoS? | 14:05 |
| ralonsoh | right (I was just asking to make it public here) | 14:06 |
| slaweq | possiblity to set max conntrack entries per zone, not globally | 14:06 |
| slaweq | currently number of connections is set on node globally and with that it could be changed per port or per network | 14:06 |
| ralonsoh | I think the idea of using the QoS API is good, IMO | 14:07 |
| ralonsoh | I would ask for a spec, because this is a complex feature, but I'm good with this | 14:08 |
| mlavalle | in priciple it is a good idea, but I | 14:08 |
| slaweq | for sure I will write spec for this before doing any code changes :) | 14:08 |
| mlavalle | would really like to see a spec | 14:08 |
| haleyb | agreed, since it took me a minute to figure out how QoS applied, but it's more just the API to get the info into neutron | 14:09 |
| haleyb | if i'm understanding it correctly | 14:10 |
| slaweq | yeap, you are | 14:10 |
| mlavalle | since a spec will be provided, +1 from me | 14:10 |
| ralonsoh | +1 | 14:10 |
| haleyb | +1 from me | 14:10 |
| opendevreview | Rico Lin proposed openstack/neutron master: Fix ovn db sync with log resources https://review.opendev.org/c/openstack/neutron/+/948053 | 14:11 |
| opendevreview | Rico Lin proposed openstack/neutron master: Update instead of recreate acl in ovn sync https://review.opendev.org/c/openstack/neutron/+/948215 | 14:11 |
| haleyb | obondarev: vote? | 14:11 |
| obondarev | +1 with the spec | 14:11 |
| haleyb | great, that's three, i'll update the rfe flags, etc | 14:12 |
| haleyb | next one i added and i see yusufgungor_ is here | 14:13 |
| slaweq | thanks | 14:13 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2107634 | 14:13 |
| yusufgungor_ | can i get your comments? do you think it is doable? | 14:14 |
| opendevreview | Rico Lin proposed openstack/neutron master: Update instead of recreate acl in ovn sync https://review.opendev.org/c/openstack/neutron/+/948215 | 14:14 |
| haleyb | yusufgungor_: can you give a short overview as it's a large descrtiption in the bug | 14:15 |
| yusufgungor_ | we aim to apply acl rules between the tenant networks so trying to send the different vxlan tenant networks traffic to the external firewall | 14:16 |
| yusufgungor_ | but using dvr and bgp, it is not possible for the instances which are located on the same host | 14:17 |
| slaweq | can you maybe use neutron-fwaas to apply SG rules on the router's level? Would that be solution for you maybe? | 14:17 |
| yusufgungor_ | we have tried the security group rules but no chance | 14:18 |
| yusufgungor_ | We cannot use Security Groups because we cannot manage ACLs centrally and easily, and as discussed in a bug report we previously submitted, packet loss during live migration increases dramatically as the number of rules grows. Neutron developers informed us that there is no definitive solution for this, and it operates on a best-effort basis. (https://bugs.launchpad.net/neutron/+bug/1970606) Therefore, we need to | 14:18 |
| yusufgungor_ | route the traffic between tenant networks through a physical firewall. | 14:18 |
| ralonsoh | so what you are basically proposing is a way to, via configuration, revert https://review.opendev.org/c/openstack/neutron/+/355062 | 14:19 |
| ralonsoh | is that a quick summary? | 14:19 |
| slaweq | I'm not talking abotut SGs but fwaas: https://docs.openstack.org/neutron/latest/admin/fwaas.html which is a bit different thing | 14:19 |
| yusufgungor_ | @ralansoh yes | 14:20 |
| yusufgungor_ | @slaweq you are right but we have not tried fwaas because it was deprecated once before, so we had doubts about using it | 14:22 |
| mlavalle | ralonsoh: wasn't that patch reverted here https://review.opendev.org/c/openstack/neutron/+/468075? | 14:22 |
| ralonsoh | mlavalle, sorry, the other one: https://review.opendev.org/c/openstack/neutron/+/283757 | 14:23 |
| slaweq | mlavalle isn't https://review.opendev.org/c/openstack/neutron/+/474007 adding the same again? | 14:23 |
| ralonsoh | in any case, is the code related to https://bugs.launchpad.net/neutron/+bug/1577488 | 14:24 |
| yusufgungor_ | @ralansoh yes you are right. actually one can say that this behaviour is normal because these tenant networks are belong to same address scope | 14:26 |
| slaweq | I am reading this LP once again and there is one thing which worries me. You said "instances in VXLAN tenant networks located in different routers within different projects can directly access each other if they are on the same compute host." - does it means that instances from 2 different tenant networks can talk to each other if they are on the same host? | 14:26 |
| slaweq | or am I misunderstanding something there? | 14:26 |
| yusufgungor_ | @slaweq you are right, that is the case, the instances which are on the same host can talk the each other directly on the fip netns of the host | 14:28 |
| mlavalle | I understood that from the LP | 14:28 |
| haleyb | i'm assuming only if in the same address scope? | 14:28 |
| ralonsoh | well, they can route the traffic, not talk directly | 14:28 |
| yusufgungor_ | because the external gw of the routers are the same vlan provider network. tenant networks and the provider networks also on the same address scope. (bgp requirements) | 14:29 |
| slaweq | but how - do the have somehow L2 connectivity or L3 using SNAT/FIPs ? | 14:29 |
| slaweq | ralonsoh ok, I think I understand now | 14:30 |
| yusufgungor_ | sorry, when saying directly i mean routing. (instead of the default gw of the provider networks) | 14:30 |
| ralonsoh | but I have question (because I dont' remember now the architecture) | 14:30 |
| ralonsoh | there is a FIP namespace per router, right? | 14:30 |
| slaweq | so basically neutron works as expected here, the only problem is that there is no way for the operator to apply rule which would prevent such kind of communication between different tenant networks using External network | 14:30 |
| yusufgungor_ | actually not per router, per external provider network, we have seen in our tests | 14:31 |
| slaweq | ralonsoh FIP namespace is one per external network IIRC | 14:31 |
| yusufgungor_ | @org.matrix:slaweq yes, we are looking for a way to prevent that routing | 14:31 |
| ralonsoh | hmmmm yeah, that could be a problem if we just allow routing any port inside this namespace | 14:31 |
| ralonsoh | another question: how do we create this address scopes? | 14:32 |
| ralonsoh | because this is what is allowing the routing between IPs inside the FIP namespace | 14:32 |
| haleyb | openstack address scope create ... | 14:33 |
| ralonsoh | no, I mean how are we "connecting" these subnets inside the FIP namespace | 14:33 |
| haleyb | i know we wrote a whole section in the docs for these cases so that users could allocate blocks, but think that patch is just doing it ? | 14:34 |
| haleyb | i.e. dvr_local_router.py | 14:35 |
| haleyb | it's been a while since i've looked at dvr as well | 14:35 |
| ralonsoh | If a gateway is configured and if it has internal ports that belong | 14:35 |
| ralonsoh | to the same address_scopes then no need to add the redirect rules. | 14:35 |
| ralonsoh | At the same we should also add a static route in the fip namespace | 14:35 |
| ralonsoh | for every interface that is connected to the router that belongs to | 14:35 |
| ralonsoh | the same address scope. | 14:35 |
| ralonsoh | from the patch | 14:36 |
| ralonsoh | should we also check that the port belongs to the same router of the FIP? | 14:36 |
| ralonsoh | because we can have several subnets, belonging to different routers, with the same address scope | 14:36 |
| ralonsoh | that is something legit | 14:36 |
| haleyb | we would need to loop-in someone like liushy since i think he still runs ml2/ovs/dvr in production | 14:38 |
| yusufgungor_ | actually the routes on the fip netns from different routers used to get traffic inside to the compute node when using bgp. so these routes are acceptable but they should only used for the incoming traffic to the agent gw port. not the traffic goes from qrouters to the fip netns | 14:38 |
| ralonsoh | is that something that we can reproduce without bgp? | 14:39 |
| yusufgungor_ | you check the solution file which we have added to the bug report | 14:40 |
| yusufgungor_ | https://launchpadlibrarian.net/788646867/fip-netns-ip-route-rule.txt | 14:40 |
| ralonsoh | just with two routers with dvr and several VMs in the same compute? | 14:40 |
| slaweq | haleyb I don't know about liushy but for sure liuyulong is using it in their production | 14:40 |
| haleyb | slaweq: sorry wrong nick | 14:40 |
| mlavalle | yusufgungor_: you've deployed https://launchpadlibrarian.net/788646867/fip-netns-ip-route-rule.txt and achieved the result you describe above? | 14:41 |
| yusufgungor_ | @ralonsoh i am not sure, we can try to disable bgp, removing address scopes etc to see it. if you need that | 14:41 |
| ralonsoh | not removing address scopes, that is a neutron feature | 14:42 |
| ralonsoh | but seems that can be reproduced just with a couple of routers, one FIP and one single compute node with a dvr router | 14:42 |
| yusufgungor_ | we have created a new ip table and moved the routes from the routers to the in it (from main table to that table) then make an ip rule to use this table for only the exiting traffic from qrouters to the fip netns | 14:42 |
| ralonsoh | if that is the case, that could be much easier to test | 14:42 |
| yusufgungor_ | * sorry, that would be incoming traffic | 14:43 |
| haleyb | brb, doorbell | 14:43 |
| yusufgungor_ | @ralonsoh i hope | 14:44 |
| ralonsoh | yusufgungor_, in any case, is this isolation breaking the previous feature? | 14:44 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/474007 ^ | 14:44 |
| ralonsoh | (I'm not saying this is bad if there is a bug) | 14:44 |
| yusufgungor_ | @ralonsoh as far as I understand, no | 14:45 |
| yusufgungor_ | actually that behaviour is not a problem for the most of the neutron users. Keeping the same tenant network traffic on the same host is acceptable. But in our case we have SOX cybersecurity compliance and find a way to disable this behaviour | 14:46 |
| yusufgungor_ | we can make the change using a new flag like isolate_tenant_networks etc and keep the old behaviour as default | 14:46 |
| yusufgungor_ | * same tenant network traffic = same address scoped tenant network | 14:47 |
| ralonsoh | ok I think you should propose a patch for Neutron but with a good documentation and testing | 14:48 |
| yusufgungor_ | the probability of this patch coming from the community is almost zero, right? Just asking to be sure 😀 | 14:49 |
| mlavalle | unlikely | 14:49 |
| ralonsoh | I don't think so but you can ask via mail | 14:49 |
| ralonsoh | btw, this is not strictly a bug, as you asked in the LP | 14:50 |
| yusufgungor_ | I asked to forward this to my manager regarding the time spent on development, thanks | 14:50 |
| yusufgungor_ | yes it is not a bug when you look at from the address scope site, but using the address scopes is not a choice, it is must when using dynamic routing | 14:51 |
| haleyb | ok, so it sounds like we need a spec? | 14:52 |
| ralonsoh | I think so, at least to describe this new feature | 14:52 |
| yusufgungor_ | ok but i can't make promises, I need to talk to my manager about making time | 14:53 |
| haleyb | sure, so then should we vote? it seems there is a need for this | 14:53 |
| mlavalle | understood | 14:53 |
| mlavalle | +1 | 14:53 |
| ralonsoh | +1 | 14:54 |
| obondarev | +1 | 14:54 |
| haleyb | +1 | 14:54 |
| haleyb | yusufgungor_: thanks for bringing it up | 14:54 |
| slaweq | +1 | 14:55 |
| haleyb | since we don't have much time will move on to last rfe | 14:55 |
| yusufgungor_ | thanks you for your time guys 🙏 | 14:55 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2092271 | 14:55 |
| ralonsoh | very quick | 14:55 |
| ralonsoh | I'm implenting that in https://review.opendev.org/q/topic:%22bug/2092271%22 | 14:55 |
| ralonsoh | but when doing the last patches (https://review.opendev.org/c/openstack/neutron/+/947906) | 14:55 |
| ralonsoh | There was a report about ovn-octavia-provider | 14:56 |
| ralonsoh | that is relying on lrp.gateway_chassis | 14:56 |
| ralonsoh | the patch for this project: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/943243 | 14:56 |
| ralonsoh | my question: can we backport it to 2025.1, send a mail to upgrade to this version and then implement the change in neutron in 2026.1? | 14:57 |
| ralonsoh | I'm saying this because if we cannot do this (the backport) | 14:57 |
| ralonsoh | we would need to wait for 2027.1 | 14:57 |
| ralonsoh | at this point, I'll be closer to my retirement! | 14:57 |
| ralonsoh | I know I'm blending a bit the SLURP release cadence by asking for this backport (https://review.opendev.org/c/openstack/ovn-octavia-provider/+/943243) | 14:58 |
| haleyb | we all will :) | 14:58 |
| ralonsoh | if we all agree with this, I'll send the backport, the releases patch for a new release and a mail | 14:58 |
| haleyb | ralonsoh: i don't think the backport to 2025.1 would break anything as it does check for ha_chassis_group | 14:59 |
| ralonsoh | not at all, the backport won't break anything | 14:59 |
| slaweq | if it won't break things I am fine with it | 15:00 |
| haleyb | ralonsoh: the other thing i saw you mention is there is no neutron requirement there, does that need to be addressed? | 15:00 |
| haleyb | separate issue i suppose | 15:01 |
| ralonsoh | hmmmm I thought that was mandatory for any project. ovn-octavia-provider requires neutron | 15:01 |
| ralonsoh | yes, separate issue | 15:01 |
| ralonsoh | let me check that and I'll raise that topic next week | 15:01 |
| ralonsoh | (or open a LP bug) | 15:01 |
| haleyb | i only saw neutron-lib in requirements.txt just now | 15:01 |
| haleyb | ack | 15:02 |
| haleyb | +1 for backport | 15:02 |
| mlavalle | +1 | 15:03 |
| ralonsoh | thank you folks | 15:03 |
| haleyb | we can all retire before 2027.1 now :) | 15:03 |
| ralonsoh | yeah! | 15:03 |
| obondarev | +1 | 15:03 |
| ralonsoh | (sorry for the extra time) | 15:03 |
| haleyb | np | 15:04 |
| slaweq | haleyb yeah \o/ | 15:04 |
| haleyb | that was the last item, anything else? if not have a nice weekend everyone! | 15:04 |
| haleyb | #endmeeting | 15:04 |
| opendevmeet | Meeting ended Fri Apr 25 15:04:54 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-04-25-14.00.html | 15:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-04-25-14.00.txt | 15:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-04-25-14.00.log.html | 15:04 |
| haleyb | o/ | 15:04 |
| ralonsoh | have a nice weekend! | 15:04 |
| slaweq | thx, have a nice weekend all | 15:05 |
| obondarev | \o | 15:05 |
| mlavalle | \o | 15:05 |
| haleyb | yusufgungor_: feel free to ping me, or ask in the bug, if you have question on proposing a spec | 15:05 |
| yusufgungor_ | ok, thanks @haleyb | 15:07 |
| sahid | haleyb: o/ if you have a moment, this is still blocked by your vote https://review.opendev.org/c/openstack/neutron/+/940983 | 15:17 |
| sahid | thanks in advance | 15:17 |
| opendevreview | Merged openstack/ovn-octavia-provider master: Prepare to handle ha_chassis_group for LRP https://review.opendev.org/c/openstack/ovn-octavia-provider/+/943243 | 16:28 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: Add neutron-tempest-plugin-fwaas-ovn job https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/947587 | 17:28 |
| -opendevstatus- NOTICE: Gerrit is getting restarted to pick up container image updates. It should only be gone for a moment. | 18:16 | |
| opendevreview | Miguel Lavalle proposed openstack/neutron master: [DNM] Debug L3 HA fullstack tests https://review.opendev.org/c/openstack/neutron/+/948280 | 23:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!