| opendevreview | Helen Chen proposed openstack/neutron master: Created OVN Agent EVPN extension & netlink monitor https://review.opendev.org/c/openstack/neutron/+/984409 | 02:09 |
|---|---|---|
| opendevreview | Brian Haley proposed openstack/neutron master: WIP: Add project_id attributes for neutron-lib change https://review.opendev.org/c/openstack/neutron/+/986962 | 02:22 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron-specs master: Add spec for Port Groups for Security Group Rules https://review.opendev.org/c/openstack/neutron-specs/+/987786 | 02:38 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron-specs master: Add spec for Port Groups for Security Group Rules https://review.opendev.org/c/openstack/neutron-specs/+/987786 | 03:11 |
| opendevreview | Brian Haley proposed openstack/neutron master: WIP: Add project_id attributes for neutron-lib change https://review.opendev.org/c/openstack/neutron/+/986962 | 04:29 |
| opendevreview | Brian Haley proposed openstack/neutron master: WIP: Add project_id attributes for neutron-lib change https://review.opendev.org/c/openstack/neutron/+/986962 | 06:19 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Use ``query.first() is not None`` to check resources https://review.opendev.org/c/openstack/neutron/+/986513 | 06:41 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add security-groups-default-statefulness API definition https://review.opendev.org/c/openstack/neutron-lib/+/984354 | 07:01 |
| ralonsoh | hey folks, if you have a couple of mins, please check https://review.opendev.org/c/openstack/neutron/+/986814 | 07:10 |
| ralonsoh | thanks! | 07:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add security-groups-default-statefulness API definition https://review.opendev.org/c/openstack/neutron-lib/+/984354 | 09:36 |
| opendevreview | Merged openstack/neutron master: Add missing address_group CRUD and action policy rules https://review.opendev.org/c/openstack/neutron/+/986814 | 09:53 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Split L3RpcNotifierMixin to avoid RPC callbacks for OVN https://review.opendev.org/c/openstack/neutron/+/987502 | 10:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == Add ``l3-agent-scheduler-ha-priority`` extension for ML2/OVN https://review.opendev.org/c/openstack/neutron/+/982792 | 11:21 |
| ralonsoh | eolivare, hello! the non-voting tempest bgp job is a but unstable | 11:26 |
| ralonsoh | and we see several retries that slow down the CI | 11:26 |
| ralonsoh | do you mind if I push a patch to set attemps=1 in this job? | 11:26 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: Add compute1 node to BGP multinode tempest job https://review.opendev.org/c/openstack/neutron/+/986075 | 11:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Set attempts=1 in ``neutron-ovn-bgp-tempest-multinode`` job https://review.opendev.org/c/openstack/neutron/+/987828 | 11:30 |
| ralonsoh | eolivare, ^ | 11:30 |
| mlavalle | haleyb: are we meeting today? | 13:03 |
| haleyb | mlavalle: i had asked ralonsoh to run today's meeting yesterday as i have an appointment i need to leave for in a minute | 13:04 |
| mlavalle | ack | 13:05 |
| *** haleyb is now known as haleyb|out | 13:08 | |
| * mlavalle assumes no meeting today | 13:16 | |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Use Neutron FIP UUID as OVN ``NAT`` row UUID https://review.opendev.org/c/openstack/neutron/+/984408 | 13:17 |
| ralonsoh | mlavalle, there is an agenda and I'm going to chair the meeting | 13:17 |
| ralonsoh | there are 2 topics to be discussed | 13:17 |
| ralonsoh | upsss | 13:18 |
| ralonsoh | the meeting is at 1300UTC, my bad | 13:19 |
| ralonsoh | #startmeeting neutron_drivers | 13:19 |
| opendevmeet | Meeting started Fri May 8 13:19:11 2026 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:19 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:19 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 13:19 |
| ralonsoh | I need to update my calendar | 13:19 |
| ralonsoh | one sec, the agenda is loading... | 13:19 |
| ralonsoh | Ping list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh, cardoe | 13:20 |
| lajoskatona | o/ | 13:20 |
| cardoe | o/ | 13:20 |
| ralonsoh | sorry for the delay, I had this meeting in my calendar 1 hour later, my bad | 13:20 |
| cardoe | so did I | 13:20 |
| ralonsoh | hmmmm I don't know if other folks are going to join | 13:21 |
| ralonsoh | that was my bad for calling this meeting so late | 13:21 |
| ralonsoh | slaweq? mlavalle? | 13:22 |
| slaweq | hi | 13:22 |
| slaweq | sorry, I forgot what time it is | 13:22 |
| slaweq | I am here | 13:22 |
| ralonsoh | ok, we have a couple of topics, I hope we don't need to vote | 13:23 |
| ralonsoh | first one | 13:23 |
| ralonsoh | #link https://review.opendev.org/c/openstack/neutron/+/985732 | 13:23 |
| ralonsoh | proposed by cardoe | 13:23 |
| cardoe | I'm just looking for some feedback as to what path forward you'd like | 13:24 |
| cardoe | It's not clear to me from the review comments as to what's our next path | 13:24 |
| ralonsoh | so, IMO, we should do a couple of things | 13:25 |
| cardoe | Cause it says to add a new exception but it's got one | 13:25 |
| ralonsoh | 1) create a specific exception for this case | 13:25 |
| ralonsoh | 2) handle the HPB, just in case we raise this exception in a higher level, to undo the previous ones | 13:26 |
| ralonsoh | and in MechanismManager.bind_port, report another log error | 13:27 |
| slaweq | I will need to go deeper into this but for now I don't really get why to do that. Drivers are kinda independed of each other, why one want to be so much "selfish" to say something like 'if I can't bind this port, nobody will' | 13:28 |
| ralonsoh | yeah that is a very exceptional case, to be honest | 13:29 |
| ralonsoh | that is required by Ironic and should be handled with care. As you said, we should let all drivers to first check if they can bind | 13:29 |
| ralonsoh | but this is something exceptional | 13:29 |
| lajoskatona | slaweq: +1 | 13:30 |
| cardoe | So this is for layered binding | 13:30 |
| cardoe | So the lower segments say this cannot bind. It's definitely not a common case but a special case where things break. | 13:31 |
| lajoskatona | can't we say that there is a cfg option and if you set it your drivers can stop the binding process and make it fail for all, but the default is to have it as it is now? | 13:31 |
| cardoe | Sure. There's no ability to raise a stop right now at all. | 13:31 |
| ralonsoh | lajoskatona, if we implement this kind of capability (stop binding), I would prefer not to have a config option | 13:32 |
| ralonsoh | is the mech driver reponsibility to be correctly implemented and to provide a responsible and justified exception in that case | 13:32 |
| slaweq | ralonsoh I agree, if we want to do it that way, we should try to do it without another config knob | 13:32 |
| lajoskatona | that can break things, but not sure how other drivers use the HPB | 13:32 |
| ralonsoh | lajoskatona, I know I know | 13:33 |
| cardoe | What's HPB? | 13:33 |
| ralonsoh | hierchical port binding | 13:33 |
| lajoskatona | hyerarchical port binding, sorry | 13:33 |
| cardoe | ah okay | 13:33 |
| slaweq | cardoe sorry for having those doubts now, I know it was discussed during PTG already, I was just not that much into this topic then. I am not going to block this as it was already agreed that should be changed. I just wanted to understand it better | 13:33 |
| cardoe | This is for HPB | 13:34 |
| cardoe | So the top layer works but the bottom layer cannot work. | 13:34 |
| ralonsoh | so, for example, apart from Ironic, I don't know other mech drivers that will implement this. If we do this, it will be the responsibility of this driver to provide a justification for this binding stop | 13:34 |
| ralonsoh | that's a lot of "power" for a single mech driver | 13:35 |
| cardoe | e.g. I'm touching a fabric in layer 0 and then touching a switch with the physical port in layer 1. | 13:35 |
| cardoe | layer 0 works and configures the fabric plane | 13:38 |
| cardoe | But then the switch itself fails to take the changes | 13:38 |
| cardoe | You need to not say that this binding worked and let Nova think that this port is bound | 13:38 |
| cardoe | And you need to have the ability to unwind the change. | 13:38 |
| slaweq | cardoe isn't port in `binding_failed` state in such case? | 13:38 |
| ralonsoh | TheJulia, hi! ^^ can you answer that? | 13:40 |
| cardoe | But neutron will still attempt to bind with another driver no? | 13:40 |
| cardoe | It also won't unwind for us in reverse order? | 13:40 |
| ralonsoh | I think the problem was that: if the expected layer 2 fails and Neutron tries, succesfully, to bind this port to another driver | 13:41 |
| slaweq | ahh, and then we end up in situation where port is bound on different layers with potentially "uncompatible" drivers, correct? | 13:42 |
| ralonsoh | from the LP bug: | 13:42 |
| ralonsoh | but the other issue is the silent failure can still cause the binding process to continue into other ML2 plugins which might believe they have successfully bound the port, which means the port likely suggests binding was successful. | 13:43 |
| cardoe | slaweq: exactly | 13:43 |
| ralonsoh | so this "exception" wants to prevent this explicitly: if a driver knows that must be bound to itself but that doesn't happen, stop any further try | 13:43 |
| slaweq | and to avoid that in case if layer 1 binding with proper mechanism driver failed tell neutron "stop, we need to revert uper level bindings and don't try to bind on this layer with others" | 13:43 |
| TheJulia | huh, what | 13:44 |
| cardoe | So like in my chain, we've got the l2vni as the top layer and then n-g-s as the lower layer and then BGP as the lowest layer. | 13:44 |
| TheJulia | where should I start reading? | 13:44 |
| ralonsoh | TheJulia, we are talking about https://review.opendev.org/c/openstack/neutron/+/985732/1/neutron/plugins/ml2/common/exceptions.py | 13:44 |
| ralonsoh | in particular, why do we need this new "exception" | 13:44 |
| ralonsoh | I copy/pasted a snippet ^ | 13:45 |
| cardoe | sorry split brain because my boss is having a 1:1 with me | 13:45 |
| lajoskatona | so this is not changing the contract we give to binding users by stopping it but actually making it work as it should have worked from the beggining? | 13:45 |
| TheJulia | I mean, any exception | 13:45 |
| ralonsoh | lajoskatona, well, the current contract is "I can't, you try now". That will break it | 13:46 |
| TheJulia | Any special exception would do the needful, the key is "this will never work, the plugin has enough visibility to know that its impossible. It has a duty to set context otherwise there is a casm of lacking context and expectations of users not met. | 13:46 |
| slaweq | ralonsoh maybe we can avoid doing that "hard stop" for the level 0 binding | 13:46 |
| TheJulia | So, y'all can extend trust that a plugin author is doing the needful, or you can rip your plugin interface out if you want to expect all drivers to always be successful because thats not operational reality | 13:46 |
| slaweq | and allow it only in other levels | 13:46 |
| TheJulia | And I'm sorry if that is coming off as harsh, but I'm sort of a bit frustrated with having an interface, and then second guessing what a plugin knows/can verify | 13:47 |
| TheJulia | since its a plugin | 13:47 |
| ralonsoh | slaweq, but level 0 can work but not the upper one. This is why we need a mechanism to revert the binding | 13:47 |
| ralonsoh | TheJulia, I think this is doable but we need to document it well and that will leave on the driver shoulders the responsibility of knowing when the binding should hard stop | 13:48 |
| slaweq | isn't it that it starts with level=0 always and then move on only for HPB? In case of "normal" ports where there is only one level of binding, it would always be level=0, no? | 13:48 |
| TheJulia | To be super blunt, I've also not had time to revisit the original patch, because I've been burried under high priority items. | 13:48 |
| TheJulia | in theory, you only find out say level 1 or 2 (if there was a level 2) has a failure if the driver is in the weeds | 13:49 |
| TheJulia | at which point, either allow port deletion/unbind to unwind level 0, or we handle the flow and unwind in code | 13:50 |
| TheJulia | The latter being way more complicated, but also you need some of that to understand the root failure too | 13:50 |
| TheJulia | so, in effect, unwind is also erasing context unless logging is clear enough | 13:50 |
| TheJulia | either way is navigatable | 13:50 |
| TheJulia | ralonsoh: totally fair to document, just humans only have so much capacity and focus at any given moment. | 13:51 |
| ralonsoh | slaweq, so far, only Ironic is using the HPB. And it will be Ironic the only driver using this new "hard stop" plug, for now | 13:52 |
| ralonsoh | we always start on level=0, yes. And for in-tree drivers is the only one used | 13:52 |
| cardoe | I'd happy to pick up the work. | 13:54 |
| cardoe | I'd just like to understand what the next steps | 13:54 |
| lajoskatona | thanks, it is a complicated part of the networking :-) | 13:54 |
| ralonsoh | I would first implement the exception in neutron-lib, to be shared with other projects | 13:55 |
| ralonsoh | and then I would continue with the Neutron patch, considering carefully the unwinding part in case of HPB error in upper levels | 13:56 |
| TheJulia | ralonsoh: fair, we'll likely want some additional logging there in that case as well, but nothing horrible. | 13:56 |
| slaweq | makes sense, I am fine with it | 13:57 |
| slaweq | and I have now slightly better understanding of the issue :) | 13:57 |
| TheJulia | cool! | 13:57 |
| ralonsoh | ok, I think we can jump to the next topic | 13:58 |
| ralonsoh | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/GIDECROTNN2SOF3QXIDKYNJNLDZJRKV6/ | 13:58 |
| ralonsoh | cardoe, please | 13:58 |
| cardoe | The next one is hairy as well. | 13:58 |
| opendevreview | Merged openstack/neutron stable/2026.1: Fix deletion of floating IPs with managed DNS records https://review.opendev.org/c/openstack/neutron/+/987742 | 13:58 |
| cardoe | So we need multiple pools of VNIs for VXLAN | 13:58 |
| cardoe | We've seen that with Jakub and Helen's spec and implementation, they're making a pool of VNIs. | 13:59 |
| ralonsoh | for evpn, yes | 13:59 |
| ralonsoh | there is a provisional implementation of the DB layer | 14:00 |
| cardoe | Which they've already said they'll need more pools in the future. | 14:00 |
| cardoe | And it's not expandable. | 14:00 |
| ralonsoh | sorry, what does it mean? | 14:00 |
| slaweq | but what they are doing is one pool which will be allocated for routers now and potentially for networks in future, it is not multiple pools AFAIU | 14:00 |
| cardoe | Today Neutron assumes that VNIs span across the entire Neutron install. | 14:01 |
| cardoe | But we've had users as recently as this week asking how to identify when that's not the case. | 14:01 |
| cardoe | The VXLAN-EVPN spec is to add VNI pools for EVPN and other pools. | 14:02 |
| slaweq | so you want something like vlan ids per provider network but with VNIs for vxlan networks. So that same VNI can be used by networks using different physical network, is my understanding correct? | 14:03 |
| TheJulia | my $0.02 is physical networks, because there is the network neutron presents to VM workloads, but there are the networks which are attached, and the needful is to begin to pull the lower level to be able to support >1 VNI which si the same number because distributed and disjointed networks are just totally a thing in the real world. | 14:04 |
| TheJulia | The only way to better bridge to that is to be able to model that | 14:05 |
| cardoe | So far what I've been modeling has been that VXLAN can use physical_network but different than VLAN. | 14:05 |
| cardoe | It can have "None" or it can have a string. | 14:05 |
| cardoe | The current behavior of VXLAN is an overlay that touches everything is the physical_network=None case. | 14:06 |
| cardoe | But if I ask a provider come along and create VXLAN VNI 20000 on physical_network=foo, that's a DIFFERENT pool / fabric / (insert name of your choice) than physical_network = None. | 14:06 |
| ralonsoh | but your proposal doesn't clash with https://review.opendev.org/c/openstack/neutron/+/987250 | 14:07 |
| cardoe | ralonsoh: no. making a separate allocation pool implementation that's a copy and paste of the VxlanAllocation class with a sed to the name and the table in the DB is silly. | 14:08 |
| ralonsoh | I mean, your proposal is something different. The EVPN feature that is implemented ^^ does not map VXLAN neutron networks with physical networks | 14:08 |
| cardoe | You're creating another VXLAN fabric in their spec. | 14:09 |
| cardoe | That's separate from the current "overlay network" as you've called it that OVN operates with. | 14:09 |
| TheJulia | cardoe: to explicitly keep it so separate, modeled purely around point to point connections, is that largely where your saying its going in the wrong path? | 14:10 |
| slaweq | cardoe that makes sense for me what you are saying except part with `physical_network = None` - I'm not sure how that should work really in practice | 14:10 |
| TheJulia | ^^^ comes to mind, specifically because modeling it purely as point-to-point VNI allocations largely prevents effective type-2 integration with any level of integration beyond basic IP traffic flow. | 14:10 |
| TheJulia | in a point to point context | 14:10 |
| cardoe | TheJulia: yeah. It's a waste of a DB table and duplicated code that could very easily be generic and cover that use case and others. | 14:10 |
| cardoe | slaweq: sure I was just trying to maintain compat. | 14:11 |
| TheJulia | Yeah, its heading down a path to build a duplicate hyperfocused table | 14:11 |
| cardoe | Today we don't allow physical_network=None in our neutron. | 14:11 |
| cardoe | Jakub and Helen have already said they're gonna need to come back and add type-2 support and that's a different fabric / pool / (pick your name here). | 14:12 |
| TheJulia | And to do type-2 right, it really needs to be integrated | 14:12 |
| cardoe | So that means they're gonna have to copy and paste https://review.opendev.org/c/openstack/neutron/+/987250 and create yet another DB table for type-2 | 14:12 |
| cardoe | But all these implementations are only for OVN. | 14:12 |
| ralonsoh | well, the spec was very clear on the type-5 support only | 14:13 |
| cardoe | We're using the teleco model with router flavors today. | 14:13 |
| cardoe | ralonsoh: it was and it said type-2 will come afterwards. | 14:13 |
| TheJulia | So, to reframe this perhaps, I think cardoe is advocating taking the generic path now as opposed to tool down a hyper-specific path which will create technical debt | 14:13 |
| cardoe | ^^^^^^^ | 14:13 |
| ralonsoh | that makes sense... | 14:13 |
| cardoe | So what Jakub and Helen are doing today... we've got that implemented today but not for OVN | 14:14 |
| TheJulia | and that seems like the worst migration imaginable because given how deep it is, it will likely need to be done in code dynamically which... is not a habit openstack has been good at in general | 14:14 |
| cardoe | But with a custom router flavor for the specific switch hardware we're using | 14:14 |
| ralonsoh | ok, cardoe, do me a favor: send a mail to the opendiscuss mail | 14:14 |
| ralonsoh | I'll make Helen and Jakub to read it, for sure | 14:14 |
| ralonsoh | we can rethink the DB layer now in order to support type-2 too | 14:14 |
| cardoe | ralonsoh: what I'm also asking for is to let other router flavors use their own pools | 14:15 |
| cardoe | Cause my router's type-5 pool of VNIs is gonna be different than OVN's type-5 pool. | 14:15 |
| ralonsoh | well, you can have you own flavor and DB definitions in your repo | 14:16 |
| TheJulia | FWIW, adding it as a column difference would also make it super easy for plugins to support in the existing model around hierarchical port binding where the type-2 route is facilitating a layer-2 bridge connection as opposed to routing just traffic over a tunnel. | 14:16 |
| cardoe | ralonsoh: I don't need it to be though. | 14:16 |
| cardoe | Cause it's literally just a pool of VNIs. | 14:16 |
| cardoe | The approach that the type-5 spec takes is also awkward for the user. | 14:17 |
| cardoe | Because they've said they don't wanna implement automatic VNI allocation. But that they want to focus on the user supplying the VNI to the openstack router create call. | 14:17 |
| ralonsoh | please, comment in the DB definition 9https://review.opendev.org/c/openstack/neutron/+/987250/4/neutron/db/migration/alembic_migrations/versions/2026.2/expand/8c7db84c96c8_add_l3_evpn_tables.py) how it should be to be a generic implementation and usable in other drivers | 14:17 |
| cardoe | But then their range of VNIs is hardcoded in the neutron.conf | 14:18 |
| ralonsoh | yes, it will be the user | 14:18 |
| cardoe | There's no API call to fetch what the valid VNI range is. | 14:18 |
| cardoe | My proposed implementation uses the network_segment_range extension. | 14:18 |
| cardoe | And you create type=vxlan, physical_network=<your-pool-name-here>, minimum=FOO, maximum=BAR | 14:19 |
| cardoe | And your driver uses that network_segment_range with that physical_network value. | 14:19 |
| cardoe | That's what the first design proposal in my email was. | 14:19 |
| TheJulia | I still think there would need the ability for a creator to supply a vni though, specifically as an example, say I have a whole fabric of hosts in my garage, and I want to connect them to my office for a type-5 connetion, the vni on the remote side I'll want to map to will be constrained by the far side | 14:20 |
| cardoe | 100% | 14:20 |
| TheJulia | but, that should ideally fall into a scope which can be allocated from | 14:20 |
| cardoe | But now I can query the network_segment_range API to know what's the valid range | 14:20 |
| TheJulia | even if its 1-16 million | 14:20 |
| cardoe | and when I do openstack router create --vni 20000 foobar, it automatically marks 20000 as allocated | 14:21 |
| cardoe | So that nobody else can create that same VNI again | 14:21 |
| ralonsoh | we had a conversation yesterday about this, that is what is expected | 14:22 |
| ralonsoh | but, of course, that means we are missing the physical network | 14:22 |
| cardoe | ralonsoh: I think when we spoke before, you had said the current VXLAN implementation assumes 1 VRF? | 14:22 |
| cardoe | That's probably the best way to model this. | 14:22 |
| cardoe | Each VRF is its own pool of VNIs. | 14:23 |
| TheJulia | I mean, so, an interesting thing which might even be a needful is if you have, for example east/west style cloud (really, different norths) connections where you want VNI traffic to flow a particular way to reach those and the easiest way is in a sense, declare a different network entirely which can service the flow | 14:23 |
| cardoe | And physical_network on the VNI could just identify the VRF its a part of | 14:23 |
| cardoe | Again, I'm trying to design this in the most generic way possible and compatible way. | 14:23 |
| TheJulia | cardoe: ++, I was typing something very similar. | 14:23 |
| ralonsoh | cardoe, understood. I think your proposal actually collides with the current DB definition in patch 987250 | 14:24 |
| cardoe | ralonsoh: cause Helen and Jakub's proposal for type-5 is running things through a separate VRF technically | 14:24 |
| cardoe | ralonsoh: yep. because they're making another DB table for just 1 more VRF | 14:24 |
| cardoe | They're gonna have another VRF for type-2 | 14:24 |
| ralonsoh | yes, each network in each compute node will create an independent VFR (if I'm not wrong) | 14:24 |
| ralonsoh | please, write a mail and send it asap to the opendiscuss list | 14:25 |
| ralonsoh | we need to address this now that we are implementing the code | 14:25 |
| ralonsoh | or comment in the patch 987250 | 14:25 |
| cardoe | okay separate email or replying to my big long email? :-D | 14:25 |
| ralonsoh | any of them, I'll ask Helen and Jakub to read it and consider it | 14:26 |
| TheJulia | The whole concern I have with adding yet another VRF for type-2 is that it actually feels wrong because type-2's use model and case is entirely different where your not actually routing traffic. | 14:26 |
| TheJulia | In my mind, it feels cleaner to be able to model and bridge directly where the needful needs to be instead of using a whole vrf style config for traffic to just be bridged | 14:27 |
| ralonsoh | sorry folks, I know we started the meeting late but is even later now | 14:28 |
| ralonsoh | so we need to finish the Neutron Drivers meeting now | 14:28 |
| cardoe | Thanks for taking the time to design withme | 14:28 |
| cardoe | I'll send those emails. | 14:28 |
| ralonsoh | cardoe, please, send this mail and also comment on the patch | 14:29 |
| lajoskatona | +1 | 14:29 |
| cardoe | will do | 14:29 |
| ralonsoh | thanks everyone for attending ( TheJulia thanks for joining) | 14:29 |
| TheJulia | Thanks folks! | 14:29 |
| ralonsoh | #endmeeting | 14:29 |
| opendevmeet | Meeting ended Fri May 8 14:29:38 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:29 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-05-08-13.19.html | 14:29 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-05-08-13.19.txt | 14:29 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-05-08-13.19.log.html | 14:29 |
| * TheJulia wonders off back to the land of crypto controls | 14:29 | |
| lajoskatona | o/ | 14:29 |
| slaweq | o/ | 14:29 |
| cardoe | I'll just mention I submitted something like... https://review.opendev.org/c/openstack/neutron-lib/+/987769 | 14:31 |
| opendevreview | Merged openstack/neutron stable/2025.2: Fix deletion of floating IPs with managed DNS records https://review.opendev.org/c/openstack/neutron/+/987743 | 14:31 |
| cardoe | I've also got some other patches to Neutron for the tests to make the FakeTypeDriver actually implement ML2TypeDriver | 14:31 |
| cardoe | Cause right now it doesn't and the methods it implements have slightly different arguments. | 14:32 |
| cardoe | My only guess is that it doesn't get hit due to other mocking? I'm not really sure. | 14:32 |
| ralonsoh | this kind of change can be something merged independently, an improvement of the current code | 14:33 |
| cardoe | Just not sure if adding typing is wanted? | 14:34 |
| ralonsoh | it is expected but usually not used | 14:39 |
| ralonsoh | if you add it, better | 14:39 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Use Neutron FIP UUID as OVN ``NAT`` row UUID https://review.opendev.org/c/openstack/neutron/+/984408 | 14:58 |
| opendevreview | Merged openstack/neutron stable/2025.1: Fix deletion of floating IPs with managed DNS records https://review.opendev.org/c/openstack/neutron/+/987744 | 14:59 |
| opendevreview | Merged openstack/neutron master: Add --port option to remove-duplicated-port-bindings script https://review.opendev.org/c/openstack/neutron/+/982622 | 14:59 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add security-groups-default-statefulness API definition https://review.opendev.org/c/openstack/neutron-lib/+/984354 | 15:04 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add security-groups-default-statefulness API extension https://review.opendev.org/c/openstack/neutron/+/984356 | 15:19 |
| *** haleyb|out is now known as haleyb | 15:23 | |
| marbindrakon | o/ folks. I'm playing with a proof of concept for providing operator-defined local services (i.e. NTP, DNS, Windows KMS, Package Repos) within isolated tenant networks (https://github.com/marbindrakon/neutron-local-services-poc). My thinking is to keep this out of tree assuming I can get localport binding figured out. Would this ultimately be better off in-tree given the mech driver dependency for OVN? | 15:37 |
| cardoe | ralonsoh: okay. If its cool I'll share some typing patches and you can tell me if that style is good? | 15:41 |
| cardoe | marbindrakon: absolutely think that's great. | 15:43 |
| cardoe | I can tell you in a previous hat on, I worked on that same stuff. | 15:43 |
| cardoe | That's what Rackspace's "quark" driver does. | 15:44 |
| marbindrakon | I've previously met this use case with Contrail's local services so I've cribbed the same use model. The PoC does have to masquerade as octavia though because of some hard-coding in the mech driver | 15:45 |
| cardoe | That was their OVS implementation before there was an OVS driver in neutron. | 15:45 |
| cardoe | I just don't work in the VM space anymore. | 15:45 |
| cardoe | I would have stopped working on that around Mitaka. | 15:46 |
| TheJulia | marbindrakon: neat! One thing to keep in mind is in-tree is likely going to be much bigger hurdle when optional or easy to bolt on in a separate repo may be easier. For example, ironic has an ml2 plugin which can be loaded to trigger localnet ports, it does require ovn, but really that is really a detail | 17:18 |
| marbindrakon | TheJulia: Thanks! I'll check out what Ironic is doing there. | 17:30 |
| TheJulia | marbindrakon: fwiw, its in the networking-baremetal repository | 17:30 |
| winiciusallan[m] | ralonsoh: hi! we've talked a last month iirc about cutting a new release of n-lib and bumping it in neutron for stable branches (25.2 and 25.1). is it still planned to happen? | 19:15 |
| winiciusallan[m] | I'm needing this https://review.opendev.org/c/openstack/neutron-lib/+/976808 in these branches for a downstream fix | 19:15 |
| opendevreview | Brian Haley proposed openstack/neutron master: Upgrade to tox 4.28.0 https://review.opendev.org/c/openstack/neutron/+/985512 | 19:15 |
| opendevreview | Merged openstack/neutron-fwaas-dashboard master: Update Babel configuration https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/987487 | 19:27 |
| opendevreview | Merged openstack/neutron-vpnaas-dashboard master: Update Babel configuration https://review.opendev.org/c/openstack/neutron-vpnaas-dashboard/+/987472 | 19:49 |
| opendevreview | Brian Haley proposed openstack/neutron master: WIP: Add project_id attributes for neutron-lib change https://review.opendev.org/c/openstack/neutron/+/986962 | 21:13 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: DNM: test hack for tenant_id changes https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/987959 | 22:39 |
| opendevreview | Brian Haley proposed openstack/neutron master: WIP: Add project_id attributes for neutron-lib change https://review.opendev.org/c/openstack/neutron/+/986962 | 22:40 |
| *** kinrui is now known as fungi | 22:44 | |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!