14:00:58 <ralonsoh> #startmeeting neutron_drivers
14:00:58 <opendevmeet> Meeting started Fri Jun  2 14:00:58 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:58 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:58 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:01:04 <lajoskatona> o/
14:01:07 <ralonsoh> hello all, let's give one more minute
14:01:24 <mlavalle> we might want to ping haleyb
14:01:41 <ralonsoh> no, he's not going to attend
14:01:47 <mlavalle> ok
14:01:49 <ralonsoh> he told me that yesterday
14:02:04 <ralonsoh> ok, I think we have quorum
14:02:14 <ralonsoh> the topic we have today is
14:02:17 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2020823
14:02:21 <ralonsoh> [RFE] Add flavor/service provider support to routers in the L3 OVN plugin
14:02:23 <ralonsoh> mlavalle, please
14:03:13 <mlavalle> back in 2016 Kevin Benton implemented a framework to create routers with flavors
14:03:33 <mlavalle> in other words, a way to implement routers with different backends
14:04:36 <obondarev> btw, is it used now?
14:04:55 <ralonsoh> not really, only a few external projects used it
14:05:05 <ralonsoh> (I don't remember which ones)
14:05:10 <obondarev> got it, thanks!
14:05:17 <mlavalle> In fact, if we look in the repo under services/l3_router/service_providers you will find his attempt to disentangle the agent based routers in different drivers
14:06:07 <mlavalle> He didn't get to the final goal but he laid a good foundation that is relatively easy to reuse with the ML2 / OVN mechanism driver
14:06:53 <mlavalle> my employer has received strong signals from potential big deployers that they want to use flavored routed with ML2 / OVN
14:07:12 <mlavalle> so I created a PoC to investigate the feasability: https://review.opendev.org/c/openstack/neutron/+/883988
14:07:12 <slaweq> what backends for routers in ML2/OVN we may have?
14:07:20 <sahid> mlavalle: what is the use case (sorry for this noob question but this will help me to understand better)
14:08:06 <mlavalle> the use case is a big telco deployer who already has their own implementation of routers that they want to use under ml2/ovn
14:08:15 <mlavalle> vrouters that is
14:08:47 <mlavalle> I've been testing the PoC in my dev environment and ot works fine
14:09:12 <mlavalle> in fact, I added a README in the code where I show inital results
14:09:23 <slaweq> ahh, so they want to create router in neutron but to have own plugin/driver/whatever to create and manage it, instead of creating it in OVN as LR, is that correct?
14:10:15 <lajoskatona> this is the readme: https://review.opendev.org/c/openstack/neutron/+/883988/7/neutron/services/ovn_l3/service_providers/README.rst
14:10:20 <mlavalle> yes, if you look at the PoC, I added a service_providers folder under ovn_l3
14:10:34 <lajoskatona> I though it quite useful to see how it will work
14:10:52 <mlavalle> services/ovn_l3/service_providers
14:11:23 <mlavalle> inside it, you will find ovn.py, which isolates the ovn based routers control plane
14:11:59 <mlavalle> and also you find user_defined.py, which stands for a potential implementation of routers with a different backend
14:12:11 <obondarev> those service providers may be not related to OVN itself, right?
14:12:42 <sahid> that is really intersting.. so if tomorrow we build a full ebpf router we can plug it as well without the pain of creating a full sdn compatible with neutron api
14:12:42 <mlavalle> right now, this flavor does nothing but just log a message that it has received a request to create, update or delete a router
14:13:04 <mlavalle> obondarev: correct
14:13:09 <mlavalle> sahid: you got it
14:13:23 <ralonsoh> I have many questions about this. In ML2/OVS (or ML2/LB), Neutron is both the orchestrator and the CMS. With ML2/OVS, the CMS. How are we going to deal with all L3 operations? I mean FIPs, router interfaces, etc
14:13:27 <obondarev> so my confusion is that it lays under "ovn_l3" while might me completely unrelated to OVN
14:15:40 <mlavalle> ralonsoh: my plan is to move all the router / fip related functionality from the services/ovn_l3/service_providers/plugin.py to the ovne driver in services/ovn_l3/service_providers/ovn.py
14:15:55 <lajoskatona> obondarev: good point
14:15:57 <mlavalle> so the plugin just does the purely CMS part
14:16:29 <slaweq> I know it's crazy idea but shouldn't we then try to unifiy our l3 service plugin and ovn_l3 service plugin and use different flavors for agent based routers (ML2/OVS) and OVN routers too?
14:16:46 <ralonsoh> nonono, I would avoid this idea
14:16:58 <ralonsoh> we have two L3 implementations, OVN and OVS/LB
14:17:04 <ralonsoh> I wouldn't mix both
14:17:16 <mlavalle> obondarev: you are right. As I slowly hollow out plugin.py and move the ovn related functionality to the ovn driver, it might not make sense to keep the plugin under ovn_l3
14:17:46 <ralonsoh> we don't have the same functionalities
14:17:54 <obondarev> mlavalle: ack
14:17:59 <mlavalle> for now, I am just slowly hollowing it out, to disentangle the CMS and ovn functionality
14:18:59 <obondarev> so it sounds pretty much what Kevin's goal was, no? What's the main difference?
14:19:13 <mlavalle> so ralonsoh is absolutely correct in that a big chunck of what needs to be done is to disentabgle the CMS part from the OVN part
14:20:09 <mlavalle> obondarev: it is the exact same idea. Just that he attacked it from the agent based implementation, while I am coming from the OVN side, where it is proving to be much simpler
14:21:14 <mlavalle> once we isolate the ovn part in a driver, we now can add other drivers
14:21:29 <racosta> mlavalle, would only the routers be managed with multiple backends? what about subnets?
14:22:27 <mlavalle> racosta: at this point I haven't uncovered anything that seggests that we might need to mess with subnets
14:22:58 <mlavalle> but in any case, that is why I am doing it gradually and as I move functionality to the driver, I'm testing it
14:23:14 <ralonsoh> so, in a nutshell, anything related to LR, LRP or NAT will be skipped from the OVN L3 point of view and the needed calls to the external routers will be made. Is that correct?
14:23:45 <mlavalle> ralonsoh: those calls will be done from the ovn driver
14:24:04 <mlavalle> and their counterparts for a different flavor, from a different driver
14:24:18 <mlavalle> like the sample one I've included in the PoC
14:25:31 <ralonsoh> (well, at least everything related to OVN l3 seems to be in one single file)
14:26:02 <ralonsoh> in any case, the idea of having this driver controller looks fine, with a common API for all drivers
14:26:49 <lajoskatona> +1
14:26:52 <ralonsoh> any other question?
14:27:02 <ralonsoh> I have one: do we need a spec? I think so
14:27:08 <lajoskatona> do we need a spec of the RFE is enough?
14:27:14 <obondarev> in the PoC I see create/update/delete router methods moved to ovn driver, but for example "add_router_interface" is still in ovn l3 plugin. Is it going to be moved as well?
14:27:17 <lajoskatona> yeah the same :-)
14:27:37 <mlavalle> obondarev: yes, I'm doing this gradually, as I said above
14:28:00 <mlavalle> I want to tackle the challenges gradually
14:28:29 <mlavalle> the idea is to isolate all the ovn related functionality in its associated driver
14:28:53 <obondarev> just want to realise what would be the difference between ovn l3 plugin and it's parent class in the end?
14:29:16 <mlavalle> obondarev: in the end there will be very little, if any
14:29:58 <obondarev> so why not just have different l3 plugin for those who needs new backend?
14:30:12 <mlavalle> that is why I think of this process as hollowing out the ovn l3 plugin. It will be reduced purely to its CMS functionality
14:31:20 <slaweq> IIU the reason to do it that way is that You can't have e.g. 2 different l3 service plugins enabled at the same time, and with this approach You may have "mixed" routers
14:31:26 <mlavalle> I think we need a unified plugin that allows users to use routers of different flavors at the same time
14:31:29 <slaweq> *IIUC
14:31:40 <ralonsoh> right, we don't have the concept of multiple L3 plugins
14:32:01 <obondarev> ah, right
14:32:38 <ralonsoh> (multiple L3 plugins loaded at the same time, I meant)
14:32:42 <mlavalle> which was ultimately Kevin's goal. He just got bogged down with all the spaghetti in the agents based implementation
14:33:00 <obondarev> I think a spec with a diagram of L3 plugins & drivers would be nice to have
14:33:20 <mlavalle> it so happens that his goal is simpler to achieve coming from the ml2/ovn side
14:34:39 <mlavalle> and to Kevin's credir, as I'm uncovering with the PoC, he laid a very good foundation, even though he didn't get to his ultimate goal 6 years ago
14:34:46 <mlavalle> credit^^^
14:35:47 <obondarev> so end goal is to have kind of same architecture as with ML2 plugins and drivers
14:35:56 <obondarev> plugin*
14:36:40 <slaweq> ML3 service plugin :)
14:36:47 <obondarev> nice!
14:36:49 <mlavalle> obondarev: yeah, I like the way ralonsoh put it. Neutron will do the CMS part and there will be drivers implementing different flavors for routers
14:37:04 <mlavalle> with different backends
14:37:31 <mlavalle> and in the way to that, let's isolate the ovn related bits
14:37:34 <mlavalle> in a driver
14:38:56 <ralonsoh> any other question?
14:39:09 <lajoskatona> Not from me, with a spec I like the idea
14:39:20 <slaweq> nothing more from me
14:39:29 <ralonsoh> ok, let's vote then
14:39:31 <slaweq> I think it's good idea to go with
14:39:32 <ralonsoh> +1 with spec
14:39:34 <slaweq> +1
14:39:37 <obondarev> +1
14:40:04 <lajoskatona> +1
14:40:14 <ralonsoh> perfect then, I'll update the LP bug with this result
14:40:29 <ralonsoh> something else you want to discuss?
14:40:39 <mlavalle> thanks for the time and consideration!
14:40:50 <ralonsoh> thank you all for participating and thanks mlavalle for this RFE
14:40:53 <obondarev> o/
14:40:56 <ralonsoh> have a nice weekend!
14:41:00 <lajoskatona> o/
14:41:02 <ralonsoh> #endmeeting