| opendevreview | Brian Haley proposed openstack/neutron-lib master: Remove whitespace exclusions in tox.ini https://review.opendev.org/c/openstack/neutron-lib/+/974387 | 04:44 |
|---|---|---|
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == Do not initiallize any RPC client if rpc_workers=0 https://review.opendev.org/c/openstack/neutron/+/974404 | 08:57 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 09:00 |
| ralonsoh | sean-k-mooney, hello! I've +2 https://review.opendev.org/c/openstack/os-vif/+/971231. I have just one small concern about the nested privsep calls (that are used also in other methods) | 09:49 |
| ralonsoh | I would push a patch to fix that | 09:49 |
| opendevreview | Renjing Xiao proposed x/whitebox-neutron-tempest-plugin master: Replace advanced image setup code with setup_advanced_image() https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/971709 | 09:49 |
| ralonsoh | sean-k-mooney, I'm going to propose this patch | 09:50 |
| opendevreview | Renjing Xiao proposed x/whitebox-neutron-tempest-plugin master: Replace advanced image setup code with setup_advanced_image() https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/971709 | 09:51 |
| opendevreview | Renjing Xiao proposed x/whitebox-neutron-tempest-plugin master: Replace advanced image setup code with setup_advanced_image() https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/971709 | 10:40 |
| sean-k-mooney | ralonsoh: ack nessed calls are safe but i had a minor comment to optimize it anyway | 10:42 |
| sean-k-mooney | ralonsoh: the fact that nested calls works is intentionally by the way but i agree that its nicer not too | 10:43 |
| sean-k-mooney | ralonsoh: want me to just update it now? | 10:43 |
| ralonsoh | sean-k-mooney, no no, no change (actually this same method is called in another nested methods | 10:44 |
| ralonsoh | yes, I'm checking now the privsep code | 10:44 |
| ralonsoh | but yes, it could be better not to call a privsep method in the daemon, although this is allowed | 10:44 |
| sean-k-mooney | ack hopefully stephen or gibi will have time to reive this later today | 10:45 |
| sean-k-mooney | *review | 10:45 |
| opendevreview | Renjing Xiao proposed x/whitebox-neutron-tempest-plugin master: Replace advanced image setup code with setup_advanced_image() https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/971709 | 10:47 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 10:47 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron-tempest-plugin master: Add both direction tap-as-a-service scenario test https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/973626 | 10:48 |
| opendevreview | Merged openstack/neutron stable/2024.2: [OVN] Allow multiple values in DHCPv4/v6 options https://review.opendev.org/c/openstack/neutron/+/974359 | 12:11 |
| opendevreview | Merged openstack/neutron-lib master: pre-commit: Migrate to ruff, enable autopep8 https://review.opendev.org/c/openstack/neutron-lib/+/972783 | 12:34 |
| opendevreview | Merged openstack/neutron-lib master: Migrate setup configuration to pyproject.toml https://review.opendev.org/c/openstack/neutron-lib/+/972784 | 12:34 |
| opendevreview | Merged openstack/neutron unmaintained/2024.1: [OVN] Allow multiple values in DHCPv4/v6 options https://review.opendev.org/c/openstack/neutron/+/974362 | 12:39 |
| opendevreview | Merged openstack/neutron master: Use RFC 5398 reserved AS numbers in Neutron documentation https://review.opendev.org/c/openstack/neutron/+/974042 | 12:39 |
| opendevreview | Merged openstack/neutron master: Don't delete from OVN DB ACLs not managed by Neutron https://review.opendev.org/c/openstack/neutron/+/973648 | 13:20 |
| mlavalle | haleyb: are we meeting today? | 14:00 |
| haleyb | mlavalle: yes, just a slow friday | 14:00 |
| haleyb | #startmeeting neutron_drivers | 14:01 |
| opendevmeet | Meeting started Fri Jan 23 14:01:40 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 |
| mlavalle | \o | 14:01 |
| elvira | o/ | 14:01 |
| ralonsoh | hello | 14:01 |
| slaweq | o/ | 14:02 |
| haleyb | we had one item on the agenda | 14:02 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2138746 | 14:02 |
| lajoskatona | o/ | 14:02 |
| haleyb | slaweq: did cardoe reach out to you on this rfe? he mentioned it would fit well with his work | 14:03 |
| slaweq | haleyb yes, now I remember he wrote something to me on irc but it was in my evening and next day I forgot to check it :/ | 14:04 |
| slaweq | I will check that with him for sure | 14:05 |
| mtomaska | o/ | 14:06 |
| slaweq | but for now I am not sure how his VXLAN stuff can be related to the PVLAN feature which we want to implement | 14:06 |
| slaweq | maybe it can be done in some way for the backend/driver they are doing, similar to what we want to achieve with OVN for "regular" ports | 14:06 |
| haleyb | slaweq: so is this basically implemented with ACLs/PGs ? | 14:07 |
| haleyb | maybe i shouldn't be jumping to the implementation though | 14:07 |
| slaweq | the thing which we want to do - yes, it is using PGs and ACLs | 14:07 |
| elvira | yes, I think it should not involve anything else from OVN iiuc | 14:08 |
| lajoskatona | slaweq: so this not something natively supported by OVN? | 14:08 |
| slaweq | I made PoC bash script which is doing that without neutron, only using ovn commands: https://gist.githubusercontent.com/gprocunier/91ad630db6e573b966ed4008dfa79bb8/raw/0e4ce3243eba7679c6a6093414a9286808bdf40d/pvlan_poc.sh | 14:08 |
| slaweq | lajoskatona there is no native support in OVN for the PVLAN stuff AFAIK, at least nothing which would e.g. allow you to configure pvlan_community, or port type for LSP | 14:09 |
| cardoe | slaweq: it’s not VXLAN. It’s layering the segments in neutron correctly. | 14:09 |
| lajoskatona | slaweq, elvira: ack, so that is why it has to be "hacked around" with pgs and ACLs | 14:10 |
| slaweq | lajoskatona yes | 14:10 |
| ralonsoh | I would need to check the rfc, but the term "community" means only other ports in the same VLAN? | 14:10 |
| cardoe | You effectively have a nested VLAN like the other feature that’s blanking on me. | 14:11 |
| cardoe | ralonsoh: community is the top level VLAN while isolated are the child VLANs | 14:11 |
| haleyb | and what is the main driver behind this? i see it's driven out of cisco, but is it to save IPs? or just isolate them? | 14:11 |
| slaweq | cardoe but AFAIU the PVLAN stuff there are no nested vlans | 14:11 |
| ralonsoh | I didn't see anything about nested VLANs in the RFC | 14:12 |
| ralonsoh | were is this concept coming from? | 14:12 |
| slaweq | my understanding from the RFE which we got internally is that this is to isolate traffic between specific ports in the same L2 domain | 14:12 |
| cardoe | Because that’s how it’s implemented? | 14:12 |
| elvira | From the information I have I only see communities are isolated from other communities therefore the use of port groups as equivalent, but they are in the same VLAN | 14:12 |
| slaweq | so in our case it would be just set of ACLs and PGs for the LS in OVN | 14:13 |
| cardoe | You can have groupings of isolated ports. | 14:13 |
| cardoe | You’re looking at a 16 year old RFC and not the actual implementations in Cisco switches. | 14:13 |
| haleyb | instead of just creating another network/subnet? | 14:13 |
| slaweq | haleyb yes | 14:14 |
| ralonsoh | slaweq, so the grouping done by each "community" will collect ports | 14:14 |
| ralonsoh | and you'll use this PG for the ACLs, right? | 14:15 |
| slaweq | ralonsoh yes, for each community there will be PG | 14:15 |
| slaweq | and there will be also PG for promiscous ports | 14:15 |
| ralonsoh | an each community don't care about the IPs, just the ports themselves | 14:15 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 14:15 |
| ralonsoh | (there could be several subnets) | 14:15 |
| slaweq | please look at the script https://gist.githubusercontent.com/gprocunier/91ad630db6e573b966ed4008dfa79bb8/raw/0e4ce3243eba7679c6a6093414a9286808bdf40d/pvlan_poc.sh - I think it is pretty easy to get if from there | 14:16 |
| cardoe | I can have community VLAN 100 and then plug 10 ports on it. I can then mark one port as isolated. Or I can have a group of ports as isolated. To do the grouping I set a mapping as VLAN 101 to be an isolated group inside of community 100. | 14:16 |
| haleyb | cardoe: to be fair, the RFC is the source of truth, and noone except for cisco knows how they really implemented it | 14:16 |
| ralonsoh | slaweq, yes, that's only to clarify that | 14:16 |
| slaweq | cardoe so IIUC Cisco is implementing that using VXLANs in their switches, right? | 14:16 |
| cardoe | haleyb: it’s also marked as informational and succeeded by the actual implementations | 14:16 |
| cardoe | slaweq: nope. Different model of switches. | 14:16 |
| cardoe | I’m running PVLAN in our old environments and moving away from that to VXLAN. | 14:17 |
| ralonsoh | but let's focus on the ML2/OVN implementation | 14:17 |
| ralonsoh | slaweq, provided a valid POC | 14:17 |
| slaweq | ralonsoh ++ | 14:17 |
| ralonsoh | will that be another ml2 driver? same as vlan, vxlan, geneve, etc? | 14:18 |
| slaweq | so our idea (mine and elvira's) is to implement that as new service pluggin and be able to have drivers for different backends | 14:18 |
| slaweq | we would like to do that with OVN ACLs and PGs but maybe there will be need for different backend implementation in future | 14:19 |
| lajoskatona | you mean do it with OVS for example? | 14:19 |
| elvira | lajoskatona: yes! if needed, anyone could implement it there | 14:19 |
| slaweq | lajoskatona if someone would want that, why not | 14:19 |
| ralonsoh | slaweq, what will be the scope of your RFE? ML2/OVN only? | 14:19 |
| ralonsoh | (yes, is in the title...) | 14:20 |
| slaweq | or maybe using the VXLAN segments which cardoe mentioned | 14:20 |
| cardoe | slaweq: its not VXLAN segments... it's just neutron segments | 14:20 |
| lajoskatona | elvira, slaweq: ack, I check with Ericsson if it is something they interested | 14:20 |
| cardoe | slaweq: which have an order inside of neutron along with helpers for top and bottom | 14:20 |
| slaweq | ralonsoh yes, we would like to focus on the ML2/OVN backend | 14:20 |
| slaweq | cardoe so you are talking about segments which we actually currently have in the neutron, right? | 14:21 |
| cardoe | correct | 14:21 |
| slaweq | but I'm not sure it is the same thing | 14:21 |
| slaweq | as PVLANs are described in that RFE | 14:21 |
| cardoe | To handle the grouping aspect we used segments | 14:22 |
| cardoe | We've got a VLAN based network that's the community. Implicitly you've got a segment always that's at [0]. We then stick other VLAN segments at [1] and those are the isolated groups. | 14:23 |
| cardoe | The trick is the port has to bind to either the [0] or the [1]. | 14:23 |
| cardoe | I'm not saying this is complete in upstream neutron today. | 14:23 |
| slaweq | and how promiscous ports are done there? | 14:23 |
| cardoe | Some of what you're proposing as well to label them. | 14:24 |
| cardoe | I'm just trying to say there's some overlap with my diagrams and what I've been trying to explain around the levels of the segments. | 14:24 |
| slaweq | ok | 14:25 |
| cardoe | None of these parts are upstreamed. | 14:25 |
| cardoe | That environment runs Cisco's OVSDB thing on their switches and its running old patched neutron. | 14:25 |
| cardoe | I support you working on this. I'm just saying there's overlap for the entire feature set. | 14:26 |
| cardoe | I'd love to upstream it all. | 14:26 |
| slaweq | yeah, there may be indeed some overlap | 14:27 |
| slaweq | maybe things will be more clear (for me at least) when we will write a spec and discuss it there | 14:27 |
| ralonsoh | +1 to this | 14:27 |
| cardoe | https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/configuration/layer-2-switching/cisco-nexus-9000-series-nx-os-layer-2-switching-configuration-guide-106x/m-configuring-private-vlans.html | 14:27 |
| cardoe | https://www.cisco.com/c/dam/en/us/td/i/500001-600000/500001-510000/504001-505000/504834.jpg | 14:28 |
| cardoe | specifically that picture | 14:28 |
| lajoskatona | +1 for spec | 14:28 |
| ralonsoh | sorry, let's focus on one spec only | 14:28 |
| cardoe | You'll see there's a primary VLAN that you need to have. | 14:28 |
| ralonsoh | let's avoid adding info that doesn't belong to the RFE in discussion | 14:28 |
| slaweq | cardoe my idea was that our "primary vlan" can simply be any network in neutron as it is isolated L2 broadcast domain and then inside that network we can implement groups of ports which belongs to differnt communities or are isolated | 14:29 |
| cardoe | Yep. The implementation we did with Cisco involves segments for the various secondary VLANs since you have to actually declare those as VLANs. | 14:31 |
| cardoe | I didn't write it nor did I have involvement in it. I've just inherited babysitting it. | 14:31 |
| cardoe | anyway I dont wanna derail. I'm happy to work with ya slaweq. | 14:32 |
| slaweq | cardoe ++ thx | 14:32 |
| haleyb | ok, should we vote on moving forward and writing an RFE? | 14:32 |
| haleyb | or are there other questions? | 14:34 |
| ralonsoh | +1 (plus a spec) | 14:34 |
| lajoskatona | not from me, +1 from me | 14:34 |
| lajoskatona | I mean no more questions | 14:35 |
| slaweq | of course we will propose spec with description of proposed design and API changes | 14:35 |
| mlavalle | +1 | 14:35 |
| haleyb | +1 from me | 14:35 |
| haleyb | ok, so that's quorum | 14:35 |
| haleyb | i'll approve and watch for the spec, and i'll put the link to your script in there as well | 14:36 |
| haleyb | anything else for the agenda today? | 14:37 |
| slaweq | thx a lot | 14:37 |
| elvira | thanks! | 14:37 |
| haleyb | ok, nothing else | 14:38 |
| haleyb | thanks for attending everyone, good discussion, and have a nice weekend! | 14:38 |
| haleyb | #endmeeting | 14:39 |
| opendevmeet | Meeting ended Fri Jan 23 14:39:03 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:39 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-23-14.01.html | 14:39 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-23-14.01.txt | 14:39 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-01-23-14.01.log.html | 14:39 |
| ralonsoh | have a nice weekend, folks | 14:39 |
| lajoskatona | o/ | 14:39 |
| elvira | o/ | 14:39 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Bump os-ken to 4.1.1 https://review.opendev.org/c/openstack/neutron/+/972540 | 14:39 |
| mlavalle | \o | 14:40 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron-tempest-plugin master: Add both direction tap-as-a-service scenario test https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/973626 | 14:40 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 15:28 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-fwaas master: WIP Add ovn-db-sync plugin for the FWaaS resources https://review.opendev.org/c/openstack/neutron-fwaas/+/973859 | 15:49 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-fwaas master: Add dsvm-functional tox environment https://review.opendev.org/c/openstack/neutron-fwaas/+/974443 | 15:49 |
| opendevreview | Lajos Katona proposed openstack/neutron master: [eventlet-removal] Handle systemctl stop for DHCP agent https://review.opendev.org/c/openstack/neutron/+/967902 | 15:56 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == Do not initiallize any RPC client if rpc_workers=0 https://review.opendev.org/c/openstack/neutron/+/974404 | 16:31 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: Add comment highlighting taas is ML2/OVS only https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/974040 | 16:51 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily while we restart it onto new images after an update to the build toolchain | 18:01 | |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Add event to create BGP chassis resources https://review.opendev.org/c/openstack/neutron/+/961854 | 18:06 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Add LRP SB event https://review.opendev.org/c/openstack/neutron/+/962727 | 18:54 |
| opendevreview | Merged openstack/neutron-lib master: Rehome ovn-db-sync-util related constants to neutron-lib https://review.opendev.org/c/openstack/neutron-lib/+/973833 | 19:02 |
| *** gmaan is now known as gmaan_afk | 19:39 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
