| opendevreview | Kyuyeong Lee proposed openstack/neutron stable/2026.1: [OVN] Fix shared admin_context in OVSDB monitor event handlers https://review.opendev.org/c/openstack/neutron/+/1005178 | 05:02 |
|---|---|---|
| opendevreview | Kyuyeong Lee proposed openstack/neutron stable/2025.2: [OVN] Fix shared admin_context in OVSDB monitor event handlers https://review.opendev.org/c/openstack/neutron/+/1005179 | 05:03 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron stable/2026.1: [OVN] Fix shared admin_context in OVSDB monitor event handlers https://review.opendev.org/c/openstack/neutron/+/1005178 | 06:00 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron stable/2025.2: [OVN] Fix shared admin_context in OVSDB monitor event handlers https://review.opendev.org/c/openstack/neutron/+/1005179 | 06:26 |
| opendevreview | Merged openstack/neutron master: evpn: Use branch-26.03 OVN branch for the experimental job https://review.opendev.org/c/openstack/neutron/+/1005082 | 07:38 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: vpnaas: Run VPNaaS tempest jobs with concurrency 1 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1005188 | 07:42 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: DNM == Test ``neutron-tempest-plugin-vpnaas`` scenario classes https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1004439 | 07:44 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-vpnaas master: vpnaas: Add swanctl (VICI protocol) support for strongSwan https://review.opendev.org/c/openstack/neutron-vpnaas/+/1003801 | 07:51 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-vpnaas master: conf: Move VPNaaS configuration options to neutron_vpnaas/conf https://review.opendev.org/c/openstack/neutron-vpnaas/+/1004571 | 07:51 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-vpnaas master: zuul: add OVN VPNaaS tempest job with swanctl legacy mode https://review.opendev.org/c/openstack/neutron-vpnaas/+/1003820 | 07:52 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-vpnaas master: DNM == Test ``neutron-tempest-plugin-vpnaas-ovn-sswan-swanctl`` 20 times https://review.opendev.org/c/openstack/neutron-vpnaas/+/1004432 | 07:52 |
| opendevreview | Adam Harwell proposed openstack/os-ken master: ofctl: Use the features reply ID before datapath initialization https://review.opendev.org/c/openstack/os-ken/+/1005191 | 08:11 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: ai: Add release cycle transition skill https://review.opendev.org/c/openstack/neutron/+/1004992 | 08:21 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: ovn: Remove standalone OVN Metadata agent https://review.opendev.org/c/openstack/neutron/+/998787 | 08:21 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: vpnaas: Run VPNaaS tempest jobs with concurrency 1 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1005188 | 08:28 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: DNM == Test ``neutron-tempest-plugin-vpnaas`` scenario classes https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1004439 | 08:28 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/2025.2: Use RBAC API policy to create default security group https://review.opendev.org/c/openstack/neutron/+/1002499 | 09:16 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/2025.1: Use RBAC API policy to create default security group https://review.opendev.org/c/openstack/neutron/+/1002502 | 09:23 |
| opendevreview | Eduardo Olivares proposed openstack/neutron-tempest-plugin master: bgp: Enable Neutron BGP multinode job in experimental queue https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1004935 | 09:37 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: ovn-sb: Set default ``hostname`` in ``chassis_add`` https://review.opendev.org/c/openstack/ovsdbapp/+/1005207 | 10:34 |
| LarsErikP | Any news on new neutron versions in gazpacho UCA? =) | 11:02 |
| ralonsoh | LarsErikP, you can check that in the releases patches | 11:03 |
| ralonsoh | https://review.opendev.org/c/openstack/releases/+/1004929 | 11:03 |
| LarsErikP | ralonsoh: thanks. I'm especially interested in the plans for releasing this into gazpacho-updates in the UCA. Do you know anything about that? =) | 11:07 |
| opendevreview | Merged openstack/neutron master: ovn: Filter ``bind_port()`` segments by subnet ``segment_id`` https://review.opendev.org/c/openstack/neutron/+/1004385 | 11:07 |
| ralonsoh | LarsErikP, no idea about Canonical roadmap | 11:07 |
| LarsErikP | maybe haleyb knows? I've asked him before, and he mentioned he knew someone working on that in Canonical.. | 11:08 |
| LarsErikP | Would love to see the release there, as there is some showstopping bugs for us in 28.0.0, which is fixed in >=28.0.1 =) | 11:09 |
| ralonsoh | haleyb, hi! Please review https://review.opendev.org/c/openstack/releases/+/1005112. This has been a very productive cycle and we have more new features to add | 11:14 |
| *** iurygregory_ is now known as iurygregory | 12:17 | |
| slaweq | ralonsoh: wow, this is really long list of significant new features added this cycle | 12:37 |
| ralonsoh | yeah! | 12:37 |
| haleyb | ralonsoh: will take a look, don't know how i missed all that | 12:53 |
| haleyb | LarsErikP: once https://review.opendev.org/c/openstack/releases/+/1004929 someone else here (I work at Canonical too) will be working on the downstream packaging part | 12:56 |
| haleyb | merges | 12:56 |
| haleyb | #startmeeting neutron_drivers | 13:00 |
| opendevmeet | Meeting started Fri Sep 11 13:00:55 2026 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 13:00 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh, cardoe | 13:00 |
| ralonsoh | hello | 13:01 |
| slaweq | o/ | 13:01 |
| haleyb | will wait for quorom but i counted 4 items in the list | 13:01 |
| mlavalle | \o | 13:02 |
| ichen | hello | 13:02 |
| cyyoon__ | hello | 13:02 |
| haleyb | ok we can get started | 13:03 |
| haleyb | first one is | 13:03 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2165306 | 13:03 |
| haleyb | [RFE][OVN] Add an ACL flow-sampling output type to Network Log | 13:03 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: [FWaaS] Add basic scenario test for FW attached to L2 ports https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/995695 | 13:03 |
| cardoe | o/ | 13:03 |
| haleyb | i think this was from cyyoon__ who just joined - can you give a high-level description of it? | 13:04 |
| cyyoon__ | I'm Chanyeol from KT Cloud, the author of this RFE. Happy to answer questions. | 13:04 |
| cyyoon__ | Yes, that's mine. We'd like to add an optional flow_sample output to Network Log using OVN's native ACL sampling. Existing logs would keep the current packet logging behavior by default. | 13:05 |
| cyyoon__ | The main gap is keeping sampling state⠁in sync when logs or⠈SG rules change, ACLs are⠁replaced, or Neutron runs DB sync. Neutron would manage that lifecycle, while the exporter, collector and ⠐ aggregation stay operator-managed.⠠ | 13:05 |
| * haleyb is still reading rfe | 13:07 | |
| ralonsoh | one question, this RFE proposes to update the current API, adding `[packet_log, flow_sample]`, right? | 13:08 |
| ralonsoh | only for ML2/OVN | 13:08 |
| cyyoon__ | Yes, adding an output_type field, with packet_log as the default | 13:09 |
| cyyoon__ | Yes, flow_sample would initially be supported only by ML2/OVN. | 13:09 |
| ralonsoh | and the log plugin will be in charge of handling these ACLs | 13:09 |
| cyyoon__ | Yes, the OVN logging driver would manage sampling state on the selected ACLs | 13:10 |
| ralonsoh | no more questions here, thanks | 13:10 |
| slaweq | IIUC if the output_type will be "flow_sample" logs will be in different format than they are today, but where they will be stored and who will consume them? Will this be outside of the neutron configuration, like e.g. some extra collector which will know where to look for them? | 13:10 |
| cyyoon__ | Yes, operators would configure OVS to export samples via IPFIX to an external collector. Collection, aggregation and storage would be outside Neutron | 13:11 |
| slaweq | ok, thx | 13:13 |
| haleyb | and the main goal is to track new and established connections? | 13:13 |
| cyyoon__ | Yes, to observe new and established traffic through sampling | 13:14 |
| haleyb | i didn't have any other questions | 13:16 |
| mlavalle | I don't have other questions | 13:17 |
| slaweq | me neighter, this seems like reasonable request | 13:18 |
| slaweq | and RFE is written in the way that it can be just copy-paste to be spec :) | 13:18 |
| mlavalle | straightforward | 13:18 |
| ralonsoh | For me is a +1 (with the corresponding spec) | 13:18 |
| haleyb | ok, we can vote - there were a lot of questions at the end | 13:18 |
| mlavalle | +1 | 13:19 |
| haleyb | yes, +1 from me with a spec | 13:19 |
| slaweq | +1 | 13:19 |
| haleyb | ok, great i'll mark approved | 13:19 |
| haleyb | cyyoon__: thanks for the RFE and attending, please go ahead and propose a spec, there should be a 2027.1 folder there now | 13:20 |
| cyyoon__ | Thanks everyone for the feedback. I'll prepare the spec for 2027.1 | 13:20 |
| haleyb | great, thanks! | 13:21 |
| haleyb | the next one is from ichen | 13:21 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2166025 | 13:21 |
| haleyb | [RFE] Extend BGP EVPN Type-5 to use distributed routing | 13:21 |
| ichen | I created the RFE, to extend Neutron to also support EVPN Type-5 using distributed routing. Neutron current supports EVPN Type-5 using what I call centralized routing, where the VTEP is on a network node. This RFE changes that to place VTEP on all compute nodes. | 13:23 |
| cardoe | This is most similar to how I'm doing this with bare metal and switches. | 13:25 |
| ichen | The spec is still in development, but a draft is linked to Launchpad #2166025, and jlibosv already commented. :) | 13:25 |
| ralonsoh | (I have no questions but Helen gave us yesterday, internally, a quick update on this feature) | 13:25 |
| haleyb | and what about the comment cyyoon__ added - is there any work required in OVN for this? | 13:26 |
| ichen | The spec documents a working solution, supported as of OVN 26.03 August 31, 2026. However, jlibosva has scalability concerns in the spec. | 13:27 |
| ichen | It is likely that OVN work will be needed to fully address the scalability concern. | 13:28 |
| haleyb | would that then change the design as well? | 13:28 |
| cardoe | I'm curious if you don't have a chassis per router... what's your VRF boundary? | 13:30 |
| cardoe | Cause you're already doing route leaking in the original spec | 13:31 |
| ichen | The draft spec proposes an OVN logical topology that includes a chassis router on each compute node for every VNI, i.e., per VNI, Neutron creates a chassis router on each compute node. If there are 1000 VNIs and 1000 compute nodes, then there will be 1M chassis routers in total created. This is where the scalability concern is, and reducing this number would be helpful. If this isn’t scalable on current, typical | 13:31 |
| ichen | hardware, then I expect the OVN logical topology to be different. The | 13:31 |
| ichen | There’s been brainstorming about a VRF-aware logical router. So, one logical router to provide all the VRF isolation. This will require changes in OVN. | 13:33 |
| cardoe | haleyb: I don't see needing to change the API that Helen proposes but it'll certainly change the plumbing internally. | 13:33 |
| ichen | Yes, what cardoe said above. | 13:33 |
| cardoe | ichen: okay that would make sense. But that's really some sensitive piece to get right otherwise you're leaking traffic between tenants. | 13:33 |
| cardoe | Overall from me +1 on doing this. | 13:35 |
| cardoe | Like I said, this mirrors real hardware implementations | 13:35 |
| cardoe | That's why I asked for https://review.opendev.org/c/openstack/neutron/+/1000485 | 13:36 |
| cardoe | The only other gap between what we have to do on real hardware then would be customizing ASNs | 13:36 |
| cardoe | I guess the question is the comfort level of the Neutron team around the fact that the internal implementation might change for different OVN versions. | 13:37 |
| haleyb | ok, so there could be a scalability concern as noted in the spec, but this could be addressed by future OVN work, which neutron could then take advantage of | 13:37 |
| haleyb | cardoe: right, and is just a maintenance task type update? | 13:38 |
| ichen | I would think that the finalized spec will need to wait for OVN. | 13:38 |
| cardoe | haleyb: I dunno. It depends on how they implement the VRF aware logical router and what that migration would look like. | 13:38 |
| cardoe | a VRF aware logical router would definitely make OVN feel more like hardware | 13:39 |
| cardoe | It'd bring us to wanting to have an API for the router policy table however | 13:40 |
| haleyb | so this is the only thing i'm stuck on then, and not sure how quickly the OVN team will work on it | 13:41 |
| haleyb | what do others think? | 13:42 |
| ichen | If following OVN’s release schedule, then the earliest would be OVN 27.03 in March 2027. OVN will be releasing OVN 26.09 this month. | 13:42 |
| haleyb | we do have more on agenda | 13:42 |
| slaweq | do I understand correctly that we will need to wait for ovn 27.03 at least to be able to deliver that RFE? | 13:43 |
| ichen | Not necessarily, but OVN is still investigating the performance of the current design | 13:44 |
| slaweq | ahh, ok | 13:44 |
| ichen | The current design requires, per VNI, a chassis router on each compute node. | 13:45 |
| slaweq | so we can use what is currenly there with some known limitations on scale | 13:45 |
| slaweq | and that may improve in future | 13:45 |
| mlavalle | and migration implications down the road, IIUC | 13:45 |
| cardoe | Just quickly reading (my first time seeing this) I agree with Helen that she could deliver it with how OVN works today. But they're probably right there's a performance consideration there. And if OVN 27.03 brings a new way of doing it there's a migration and how impacting that migration will be is unknown until OVN folks create the implementation. But more than likely it would be down time since you would be tearing down | 13:45 |
| cardoe | a chassis and building a new router object and moving flows and configs. | 13:45 |
| ichen | That is one approach. The other approach is to wait, either wait to approve RFE or wait to approve spec. | 13:46 |
| cardoe | I don't think Helen's API would change either way. | 13:46 |
| ralonsoh | we can approve the RFE, waiting for the needed OVN release and releasing the neutron code at this point | 13:47 |
| ichen | Migration would really mean upgrading OVN, right? | 13:47 |
| cardoe | upgrade OVN and have neutron rebuild state | 13:47 |
| ralonsoh | if there are OF rules upgrades, that could imply traffic disconnections | 13:47 |
| cardoe | ^ yeah | 13:47 |
| ralonsoh | but everything can be documented, I see no problem with the Neutron part | 13:48 |
| slaweq | I agree with ralonsoh | 13:48 |
| mlavalle | as long as potential deployers understand the migration implications down the road | 13:49 |
| haleyb | so if i'm understanding above, we can approve the RFE, but the spec and implementation would need to wait for OVN work | 13:50 |
| haleyb | i think in general it's a good feature | 13:51 |
| ralonsoh | +1 with the already WIP spec | 13:51 |
| ichen | If we don’t want to migrate, then spec and implementation would need to wait for OVN work. | 13:51 |
| mlavalle | yes, that's really the decision we need to make | 13:52 |
| ralonsoh | That could be discussed in the spec | 13:52 |
| cardoe | ichen: my only feedback would be to let different router flavors signal if they support centralized vs distributed or both. | 13:52 |
| ralonsoh | as different alternatives proposed | 13:53 |
| cardoe | ichen: e.g. my telco plugin would only support distributed for example | 13:53 |
| haleyb | ok, now i understand ralonsoh's comment - implement as-is today, when OVN support is updated, we change, documenting the data plane disruption | 13:53 |
| ichen | cardoe: ACK | 13:53 |
| ralonsoh | exactly | 13:53 |
| mlavalle | good point. approve rfe now and hash out the migration question in the spec | 13:53 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: vpnaas: Log dataplane state on pre-VPN isolation failure https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1005241 | 13:54 |
| opendevreview | Merged openstack/neutron-vpnaas stable/2026.1: Fix automatic rescheduling from dead VPN agents https://review.opendev.org/c/openstack/neutron-vpnaas/+/1004770 | 13:55 |
| haleyb | ok, so let's vote on that - approve the RFE and start working on spec | 13:55 |
| ralonsoh | +1 | 13:55 |
| mlavalle | +1 | 13:55 |
| haleyb | +1 | 13:56 |
| haleyb | ok, so please add any comments to spec | 13:56 |
| slaweq | +1 | 13:56 |
| haleyb | 4/5 so approved | 13:57 |
| ichen | Thanks! | 13:57 |
| mlavalle | is the fifth in 4/5 Lajos? | 13:57 |
| haleyb | and i don't think we have time for the others, will have to defer until next week, i'll update the wiki | 13:57 |
| cardoe | I know time is almost up but since there's a lot of folks around... I'd ask for some feedback on https://bugs.launchpad.net/neutron/+bug/2167105 my proposed fix has implications for tbachman (I might have messed up his IRC nick), for hjensas (networking-baremetal) and for myself. | 13:58 |
| haleyb | mlavalle: yes, Lajos | 13:58 |
| ralonsoh | cardoe, we can talk about this after the meeting | 13:58 |
| cardoe | We also hit an OVN maintenance worker issue yesterday where it ATE a bunch of OVN routers. I'm still trying to troubleshoot it. | 13:58 |
| ralonsoh | after this meeting | 13:59 |
| haleyb | thanks for attending, i'll end the meeting | 13:59 |
| haleyb | #endmeeting | 13:59 |
| opendevmeet | Meeting ended Fri Sep 11 13:59:17 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-09-11-13.00.html | 13:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-09-11-13.00.txt | 13:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-09-11-13.00.log.html | 13:59 |
| ralonsoh | cardoe, I'll check the trunk issue | 13:59 |
| ralonsoh | what happened with the maintenance worker? | 13:59 |
| ralonsoh | do you have a launchpad bug? | 13:59 |
| cardoe | I'm also happy sometime to do a walk through / demo / whatever folks would like to see how the bare metal drivers and neutron interact. | 13:59 |
| slaweq | haleyb: next friday I will probably not be available so my topic can be moved to Sept 25 | 13:59 |
| cardoe | ralonsoh: I haven't made a launchpad bug yet for the maintenance worker. | 14:00 |
| cardoe | ralonsoh: so due to a screw up in configs from my team we didn't have the maintenance worker running in that env and so they fixed that yesterday. | 14:00 |
| ralonsoh | but is this something related to the code? | 14:00 |
| cardoe | it started up and it was set to 2 pods in k8s so 2 copies fired up at the same time. | 14:00 |
| haleyb | slaweq: ack, i will not be there then but the other 4/5 will i hope :) | 14:01 |
| ralonsoh | there is no problem of concurrency for the maintenance worker, it is supposed to request the OVN DB lock | 14:01 |
| cardoe | one of them decided that 8 OVN routers were missing their LRP and so it triggered the generic update_port() instead of the router aware path. So it recreated the port without type=router | 14:02 |
| ralonsoh | in other words, if more than 1 maintenance process is running, only the first one will execute the tasks | 14:02 |
| cardoe | okay well more digging. | 14:02 |
| ralonsoh | cardoe, please, fill a LP bug with any possible information | 14:02 |
| cardoe | I've thrown all the logs at Claude right now and I'm letting it jump to conclusions to be honest as a starting point. | 14:03 |
| ralonsoh | also because you use baremetal ports, that is relevant for the report | 14:03 |
| cardoe | I figured I'd make a LP bug once I have some concrete info | 14:03 |
| ralonsoh | perfect | 14:03 |
| ralonsoh | I'll check the trunks one | 14:03 |
| cardoe | https://github.com/rackerlabs/understack/issues/2330 is where Claude is rambling away at. | 14:03 |
| opendevreview | Miro Tomaska proposed openstack/neutron-tempest-plugin master: Test that only one subnet with `advertise-host` is allowed per network https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1000973 | 14:04 |
| cardoe | ralonsoh: as an aside... for ichen's distributed EVPN.. she'll need https://review.opendev.org/c/openstack/neutron/+/1000485 because the physnet for the VNI will be the same across the deployment "evpn-ovn" let's say but then the VLAN side physnet will need to be the compute node | 14:05 |
| ralonsoh | I still don't know how the implementation refactor will be, but it should replicate the current evpn code, so I'm not sure about this | 14:06 |
| cardoe | Because on compute node-1 FRR will use let's say VLAN 1000 but on compute node-2 FRR will use 2000 potentially for the same connection and node-2 could use VLAN 1000 for a completely different VNI. | 14:06 |
| cardoe | Otherwise you cannot scale past 4094 EVPN links per Neutron instance. | 14:07 |
| ralonsoh | I'm aware but I'm not sure if that was an issue during the evpn initial design | 14:07 |
| cardoe | It wasn't cause they were just focused on the centralized implementation while I've been only doing the distributed version. | 14:08 |
| opendevreview | Merged openstack/neutron master: [bgp] Bump cirros version to 0.6.3 https://review.opendev.org/c/openstack/neutron/+/1002065 | 14:11 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: vpnaas: Log dataplane state on pre-VPN isolation failure https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1005241 | 14:11 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: vpnaas: Log dataplane state on pre-VPN isolation failure https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1005241 | 14:13 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: DNM == Test ``neutron-tempest-plugin-vpnaas`` scenario classes https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1004439 | 14:13 |
| opendevreview | Merged openstack/neutron stable/2026.1: [OVN] Fix shared admin_context in OVSDB monitor event handlers https://review.opendev.org/c/openstack/neutron/+/1005178 | 18:15 |
| opendevreview | Merged openstack/neutron stable/2025.2: [OVN] Fix shared admin_context in OVSDB monitor event handlers https://review.opendev.org/c/openstack/neutron/+/1005179 | 18:15 |
| opendevreview | Merged openstack/neutron stable/2025.2: Use RBAC API policy to create default security group https://review.opendev.org/c/openstack/neutron/+/1002499 | 18:15 |
| opendevreview | Merged openstack/neutron master: ovn: Add BGP password to EVPN FRR fallback templates https://review.opendev.org/c/openstack/neutron/+/1001375 | 21:03 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!