On Mon, Jun 30, 2025 at 5:34 AM Dumitru Ceara <dce...@redhat.com> wrote: > > Hi Numan, > > On 6/26/25 4:26 PM, Numan Siddique wrote: > > On Thu, Jun 26, 2025 at 8:27 AM Dumitru Ceara <dce...@redhat.com> wrote: > >> > >> Hi Frode, > >> > >> On 6/26/25 1:50 PM, Frode Nordahl wrote: > >>> On 25.06.2025 14:58, Dumitru Ceara wrote: > >>>> On 6/23/25 6:23 PM, Frode Nordahl wrote: > >>>>> Hello, All, > >>>>> > >>>> > >>>> Hi Frode, > >>>> > >>>>> Apologies for being late to the discussion, but just wanted to document > >>>>> our interest in this as mentioned in the last IRC meeting and just now > >>>>> in the A/V meeting. > >>>>> > >>>>> > >>>>> On 19.06.2025 16:18, Dumitru Ceara via dev wrote: > >>>>>> Hi Numan, > >>>>>> > >>>>>> On 6/18/25 11:38 PM, Numan Siddique wrote: > >>>>>>> On Wed, Jun 18, 2025 at 5:00 PM Dumitru Ceara <dce...@redhat.com> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi Han, > >>>>>>>> > >>>>>>>> On 6/18/25 7:40 PM, Han Zhou wrote: > >>>>>>>>> Thanks Numan for the proposal. > >>>>>>>>> > >>>>>>>>> On Wed, Jun 18, 2025 at 4:27 AM Dumitru Ceara <dce...@redhat.com> > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi Numan, Ales, > >>>>>>>>>> > >>>>>>>>>> On 6/10/25 4:24 PM, Numan Siddique wrote: > >>>>>>>>>>> On Tue, Jun 10, 2025 at 2:04 AM Ales Musil <amu...@redhat.com> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Jun 5, 2025 at 9:44 PM Numan Siddique <num...@ovn.org> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, Jun 5, 2025 at 11:33 AM Dumitru Ceara > >>>>>>>>>>>>> <dce...@redhat.com> > >>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 6/4/25 6:24 PM, Numan Siddique wrote: > >>>>>>>>>>>>>>> Hello, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Numan, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Dumitru and Numan, > >>>>>>>>>>>> > >>>>>>>>>>>> I think the project might be a good idea in general, just adding > >>>>>>>>>>>> my opinion on some parts below. > >>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> There's a need to configure the provider bridge with specific > >>>>>>>>> OpenFlow > >>>>>>>>>>>>>>> rules after packets leave the OVN pipeline and enter via the > >>>>>>>>>>>>>>> patch > >>>>>>>>>>>>>>> port. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> To simplify this for CMS, I propose utilizing OVN logical > >>>>>>>>>>>>>>> flows. > >>>>>>>>> This > >>>>>>>>>>>>>>> would eliminate the need for CMS to manage direct OpenFlow > >>>>>>>>> connections > >>>>>>>>>>>>>>> and programming. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This seems very interesting! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> To achieve this, I've developed a new service within OVN > >>>>>>>>>>>>>>> called > >>>>>>>>>>>>>>> `ovn-pr-controller` (pr = provider). Here's a high-level > >>>>>>>>>>>>>>> overview: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> A new database, `OVN_Provider`, is created with two main > >>>>>>>>>>>>>>> tables: > >>>>>>>>>>>>>>> `PR_Bridge` and `Logical_Flow`. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> `ovn-pr-controller` connects to this database, translates > >>>>>>>>>>>>>>> logical > >>>>>>>>>>>>>>> flows to OpenFlow rules, and programs the bridges. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> CMS adds logical flows for managed provider bridges by > >>>>>>>>>>>>>>> connecting to > >>>>>>>>>>>>>>> the `OVN_Provider` database. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> CMS can define the pipeline as needed. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> An `ovn-prctl` utility (similar to `ovn-nbctl`) is used to > >>>>>>>>>>>>>>> program > >>>>>>>>>>>>>>> logical flows. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Example Usage: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> # Add a provider bridge > >>>>>>>>>>>>>>> `ovn-prctl add-br br-ext` > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> # Add logical flows > >>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 0 100 "inport == \\"patch-port\\"" > >>>>>>>>>>>>>>> "ct_snat_zone = 1000; next;"` > >>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 0 0 "1” "next;"` > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 1 1000 "ip4" "ct_snat;"` > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 2 1000 "ip4 && ct.new && ct.trk && > >>>>>>>>> ip4.src > >>>>>>>>>>>>>>> == 10.0.0.11" "ct_snat(100.64.0.11); next;"` > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 2 0 "ip4" "next;"` > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 3 100 "ip4 && ip4.dst == > >>>>>>>>>>>>>>> 52.92.128.0/17" > >>>>>>>>>>>>>>> "tun.id = 1000; tun_ip4.dst = 10.100.100.1; eth.dst = > >>>>>>>>>>>>>>> 4c:96:14:14:01:b0; outport = \\"vxlan0\\"; output;"` > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 3 0 “1” “output;”` > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'd like to get the community's feedback on whether this > >>>>>>>>>>>>>>> service > >>>>>>>>> would > >>>>>>>>>>>>>>> be a valuable addition to OVN. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I wonder if we need these to be separate databases/processes. > >>>>>>>>> Wouldn't > >>>>>>>>>>>>>> it make sense to expose this in the NB database directly? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> With your proposal, these new ovn-pr-controllers would have to > >>>>>>>>> connect > >>>>>>>>>>>>>> to the central OVN_Provider database from all chassis. But we > >>>>>>>>> already > >>>>>>>>>>>>>> have the ovn-controller connection to the Southbound. Could we > >>>>>>>>> reuse that? > >>>>>>>>>>>>> > >>>>>>>>>>>>> I forgot to mention that the OVN provider ovsdb-server and the > >>>>>>>>>>>>> ovn-pr-controller needs > >>>>>>>>>>>>> to be run on each chassis. > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I see. However, I think it gives even more flexibility if the OVN > >>>>>>>>>> provider database is centralized. Then the CMS central component > >>>>>>>>>> (e.g., > >>>>>>>>>> neutron for OpenStack) could just write "logical flows" there and > >>>>>>>>>> rely > >>>>>>>>>> on per-chassis ovn-pr-controllers to translate that to OpenFlow. > >>>>>>>>>> > >>>>>>>>> While it brings flexibility, we should also keep in mind that the > >>>>>>>>> central > >>>>>>>>> approach could introduce another choke point for scale. Even if we > >>>>>>>>> reuse SB > >>>>>>>>> DB as the central component, the new ovn-pr-controllers process > >>>>>>>>> would > >>>>>>>>> require new connections to the SB DB. > >>>>>>>>> > >>>>>>>> > >>>>>>>> True, but I was not really thinking of using the SB DB as the central > >>>>>>>> component for ovn-pr-controllers but rather a new database > >>>>>>>> server. And > >>>>>>>> I really hope it wouldn't require storing as many logical flows (and > >>>>>>>> data in general) as we store in the SB today. > >>>>>>>> > >>>>>>> > >>>>>>> Thanks for the comments and the discussion. > >>>>>>> > >>>>>>> Just FYI - I thought we are in favour of having a separate project. > >>>>>>> So I reworked a bit and renamed the project to - ovnbr controller (ovn > >>>>>>> bridge controller) > >>>>>>> - https://github.com/numansiddique/ovnbr/tree/initial_commits > >>>>>>> > >>>>>>> But I can move back the code to ovn project. So not a problem. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> Supporting both central and distributed may be an overkill at least > >>>>>>>>> as a > >>>>>>>>> start, if we could decide which one is more practical from a CMS > >>>>>>>>> point of > >>>>>>>>> view. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Maybe, but the "distributed" case would probably mean more work > >>>>>>>> for the > >>>>>>>> CMS on the node side (a per chassis CMS component is definitely > >>>>>>>> required > >>>>>>>> then to provision the per chassis database). > >>>>>>>> > >>>>>>>> I do understand however that we'd need a way to abstract > >>>>>>>> chassis-specific resources (e.g., OVS ports) in the other, > >>>>>>>> "centralized", case. And that might be a significant disadvantage. > >>>>>>>> > >>>>>>>>>> On second thought, if designed properly, there's probably no need > >>>>>>>>>> to add > >>>>>>>>>> a restriction to colocate the new database and ovn-pr- > >>>>>>>>>> controller. We > >>>>>>>>>> could just support both types of deployments: > >>>>>>> > >>>>>>> @Dumitru Ceara If I understand correctly, what you're suggesting > >>>>>>> is that > >>>>>>> CMS can decide to run ovnbr database either central or locally - for > >>>>>>> each chassis. > >>>>>>> > >>>>>> > >>>>>> Yes, that's what I was thinking of. > >>>>> > >>>>> fwiw; We would be interested in the distributed database for the PR > >>>>> controller. > >>>>> > >>>>> Our interest surfaced after a discussion with Jakub Libosvar on how to > >>>>> approach downstream OpenStack Neutron consumption of OVN native BGP > >>>>> support, where he raised the following use case: > >>>>> * Single NIC chassis. > >>>>> * Said NIC is operated by OVS, for simplicity and purpose of discussion, > >>>>> let's say the user space data path. > >>>>> > >>>>> > >>>>> Now let's mix this with OVN native BGP features such as: > >>>>> * Learning the default gateway through route exchange. > >>>>> * Routing IPv4 prefixes over IPv6 next hop (aka. BGP Unnumbered). > >>>>> * BGP protocol redirect to ensure BGP next hop address is the link-local > >>>>> address of a OVN LR on the integration bridge (which may be required for > >>>>> this to work with older versions of FRR on some ToR equipment due to > >>>>> lack of support for 3rd party link-local next hop). > >>>>> > >>>>> > >>>>> With a centralized Southbound database, which a CMS such as OpenStack > >>>>> deploys, we would have a chicken and egg problem, because flows are > >>>>> needed in the integration bridge for the ovn-controller to connect to > >>>>> the Southbound database, and ... you get the picture. > >>>>> > >>>>> I imagine we could make parts of this work better with a distributed > >>>>> database for a OVN Provider Controller. > >>>>> > >>>>> I guess we could even task this distributed controller with "priming" > >>>>> the integration bridge with a simple set of "static flows" enough to get > >>>>> it bootstrapped in such topologies (or could this specific task even be > >>>>> a feature of the regular controller?). > >>>>> > >>>> > >>>> I'm just trying to make sure I understood this last part correctly. By > >>>> "regular controller" do you mean "ovn-controller" or some other (CMS) > >>>> node-specific component? > >>> > >>> I was referring to the "ovn-controller". > >>> > >> > >> Thanks for the clarification! > >> > >>> The need for a L3 interface on every chassis for BGP generates a lot of > >>> per-chassis configuration, which "pollutes" the Northbound database for > >>> CMSs that uses centralized OVN DBs for the entire deployment. > >>> > >>> The idea of a distributed database for the pr-controller made me think > >>> this distributed database could potentially also be consumed by the ovn- > >>> controller for per-chassis configuration in cases where more advanced > >>> higher layer features are required, and the CMS does not want to re- > >>> implement those in logical flows using the "pr-controller" themselves. > >>> > >> > >> Wouldn't it then make sense to just use ovn-controller for managing all > >> bridges (br-int and also all provider OVS bridges listed in the > >> distributed "Provider Database") in all cases? > > > > I thought about that too. I still feel it's better to have a separate > > service. > > Any user can just use OVN bridge/provider controller without having to use > > OVN > > to program OVS bridges. > > > > That's fair. It seems more flexible. If ever needed we can also add > support in the future for ovn-controller to take over the functionality > of the bridge/provider controller.
Thanks. Shall I start working on proposing the patches ? With - With a new service inside the ovn repo (like ovn-controller-vtep) - Name of the service - ovn-br-controller Thanks Numan > > Regards, > Dumitru > > > Thanks > > Numan > > > >> > >> Thanks, > >> Dumitru > >> > >>> -- > >>> Frode Nordahl > >>> > >>>>>>> I think that would work too. Only disadvantage is that CMS has to > >>>>>>> ensure that the bridge names and physical interface names > >>>>>>> have to be the same. Although we can definitely find a way to handle > >>>>>>> this. > >>>>>>> > >>>>>>> The present proposal schema - > >>>>>>> https://github.com/numansiddique/ovnbr/blob/initial_commits/ovn- > >>>>>>> br.ovsschema#L66 > >>>>>>> has only a Bridge table and no ports defined. In the present proposal > >>>>>>> CMS can add > >>>>>>> logical flows like - "inport == eth1 && ....." and ovnbr-controller > >>>>>>> expects an OVS interface - eth1 in the OVS bridge. > >>>>>>> > >>>>>> > >>>>>> Right, we'd need a way to represent chassis specific information if we > >>>>>> support a central ovnbr database. Probably at least: OVS ports, > >>>>>> conntrack zones, provider bridge names. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>> - ovn-pr-controller & database on the same chassis > >>>>>>>>>> - (multiple) ovn-pr-controller connecting to a database on a > >>>>>>>>>> different > >>>>>>>>>> node (e.g., colocated with the Southbound) > >>>>>>>>>> > >>>>>>>>>>>>> This is basically to allow a CMS agent running on each chassis > >>>>>>>>>>>>> to use > >>>>>>>>>>>>> logical flows > >>>>>>>>>>>>> and program them in the OVN provider database, instead of > >>>>>>>>>>>>> talking > >>>>>>>>>>>>> OpenFlow directly. > >>>>>>>>>>>>> > >>>>>>>>>>>>> OVN has a very nice way of abstracting OpenFlows using logical > >>>>>>>>>>>>> flows > >>>>>>>>>>>>> and my idea is to leverage it. > >>>>>>>>>>>>> > >>>>>>>>>>>>> ovnkube-node, as you know, programs the OpenFlow rules to the > >>>>>>>>>>>>> provider bridge directly by execing > >>>>>>>>>>>>> "ovs-ofctl". The OVN kubernetes community could possibly use > >>>>>>>>>>>>> OVN > >>>>>>>>>>>>> provider controller. > >>>>>>>>>> > >>>>>>>>>> Another thing the CMS node component (ovnkube-node in the example > >>>>>>>>>> above) > >>>>>>>>>> needs to do is reconcile flows on the "provider" bridge on restart. > >>>>>>>>>> > >>>>>>>>>> This new OVN provider controller would also remove the need for > >>>>>>>>>> the CMS > >>>>>>>>>> to do that, which is an advantage. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> It is definitely valuable, and no objection from me. But I think > >>>>>>>>> it is > >>>>>>>>> better to ask opinion from CMS component maintainers if the OVS > >>>>>>>>> pipeline > >>>>>>>>> for the provider bridge is complex enough to justify this. Also, > >>>>>>>>> how much > >>>>>>>>> would it help by managing logical flows through an OVSDB versus > >>>>>>>>> managing > >>>>>>>>> open-flow rules though ovs-ofctl. Keep in mind that the abstraction > >>>>>>>>> here is > >>>>>>>>> not at the level of the NB DB which focuses on logical topologies - > >>>>>>>>> here > >>>>>>>>> the abstraction is logical-flows (something at the SB level), so > >>>>>>>>> the CMS > >>>>>>>>> still needs to manage the pipeline rather than just logical > >>>>>>>>> topology. > >>>>>>> > >>>>>>> That's correct. Expectation is that CMS knows what it is doing, > >>>>>>> And we have the requirement to add flows in the provider bridges and > >>>>>>> hence thought > >>>>>>> of this abstraction to > >>>>>>> - leverage the OVN logical flows > >>>>>>> - and to leverage the openflow handling of ovn-controller. > >>>>>>> > >>>>>>> > >>>>>>> My personal preference is also to have it part of OVN so that it is > >>>>>>> easier to manage. > >>>>>>> > >>>>>>> But as Ales mentioned, we have many logical actions like - > >>>>>>> put_dhcp_opts etc (which use controller action) > >>>>>>> which will not work with the ovn-bridge-controller. Probably > >>>>>>> ovn-bridge-controller can maintain its own symbol table. > >>>>>>> > >>>>>>> > >>>>>>> Thanks > >>>>>>> Numan > >>>>>>> > >>>>>>> > >>>>>>>>> > >>>>>>>>> Adding @Tim Rozet <tro...@redhat.com> @Girish Moodalbail > >>>>>>>>> <gmoodalb...@gmail.com> from ovn-k8s to comment. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Adding Jakub Libosvar too, from the neutron side, as we briefly > >>>>>>>> touched > >>>>>>>> on the content of this proposal in a discussion while trying to > >>>>>>>> onboard > >>>>>>>> the OVN BGP support in neutron. IMO a centralized "provider network > >>>>>>>> database" might fit that specific use case quite well because the > >>>>>>>> open > >>>>>>>> flow rules that needed to be added to the provider bridge were quite > >>>>>>>> generic. > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>>>> I'm not suggesting this, but just giving an example or a > >>>>>>>>>>>>> potential > >>>>>>>>> user. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I believe it could be useful, but I'm unsure if it should be > >>>>>>>>>>>>>>> integrated into OVN directly or be a separate project within > >>>>>>>>>>>>>>> `ovn-org`. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> In my opinion it would be better as a standalone project within > >>>>>>>>>>>> ovn-org. There is couple of reasons why: > >>>>>>>>>>>> > >>>>>>>>>>>> 1) Separation between ovn actions and the new ones. I suppose the > >>>>>>>>>>>> ovn-pr-controller won't support like put_arp etc. in other words > >>>>>>>>>>>> actions that require userspace handling. > >>>>>>>>>>>> > >>>>>>>>>>>> 2) There are certain expectations about parameters, mostly ct > >>>>>>>>>>>> actions > >>>>>>>>>>>> and it feels a little strange to populate a specific register in > >>>>>>>>>>>> order > >>>>>>>>>>>> to get the action working. > >>>>>>>>>>>> > >>>>>>>>>>>> 3) Maintenance cost to some extent, standalone project might be > >>>>>>>>>>>> easier to maintain, it can be written in different language if it > >>>>>>>>>>>> would be better fit. > >>>>>>>>>>>> > >>>>>>>>>>>> 4) The abstraction can be generated automatically to some extent > >>>>>>>>>>>> so most of the code might be actually a way to generate the > >>>>>>>>>>>> parsing > >>>>>>>>>>>> etc. > >>>>>>>>>>>> > >>>>>>>>>>>> I'm fully aware that this would require some duplication. With > >>>>>>>>>>>> that > >>>>>>>>>>>> said, this just my opinion and I won't block any other decision. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Hi Ales, > >>>>>>>>>>> > >>>>>>>>>>> Thanks for the replies. I agree with your points. I think it > >>>>>>>>>>> makes > >>>>>>>>>>> sense to have > >>>>>>>>>>> a separate project even if the code is duplicated. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I'm not sure I see anything blocking the ovn-pr-controller (or > >>>>>>>>>> whatever > >>>>>>>>>> we decide to call it) code from being part of the ovn-org/ovn > >>>>>>>>>> project. > >>>>>>>>>> > >>>>>>>>>> It can be a standalone daemon (similar to controller/ovn- > >>>>>>>>>> controller or > >>>>>>>>>> controller-vtep/ovn-controller-vtep). > >>>>>>>>>> > >>>>>>>>>> It can even be written in a different language (e.g., rust) if we > >>>>>>>>>> wish. > >>>>>>>>>> > >>>>>>>>>> Keeping it in the same project actually reduces maintenance cost > >>>>>>>>>> because > >>>>>>>>>> we can just reuse the expr parsing library from OVN directly. > >>>>>>>>>> We can > >>>>>>>>>> also reuse all the build/test infra (if we wish). > >>>>>>>>>> > >>>>>>>>>> It would also mean we wouldn't have to come up with different > >>>>>>>>>> release > >>>>>>>>>> strategies, contribution guidelines, etc. > >>>>>>>>>> > >>>>>>>>>> Also, with downstream in mind, it might be (slightly) easier for > >>>>>>>>>> distros > >>>>>>>>>> to package this new binary if its code lived in ovn-org/ovn. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> In my option it is really not good to duplicate components in > >>>>>>>>> different > >>>>>>>>> repos. Unless we find ways to expose logical flow translation as a > >>>>>>>>> library > >>>>>>>>> and share between the projects, I am inclined to use OVN repo > >>>>>>>>> directly. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Han > >>>>>>>>> > >>>>>>>>>>> Implementing in a different language would be nice but I think it > >>>>>>>>>>> will > >>>>>>>>>>> take a lot > >>>>>>>>>>> of effort to implement expr parsing and openflow encoding. > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> Numan > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Dumitru > >>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I guess it depends a bit on the approach chosen for > >>>>>>>>>>>>>> implementation > >>>>>>>>> but > >>>>>>>>>>>>>> at a first glance this seems as a good candidate for ovn-org > >>>>>>>>>>>>>> to me. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Three possible options are: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Integrate the `OVN provider controller` into `ovn-org/ > >>>>>>>>>>>>>>> ovn`. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Create a separate project within `ovn-org` (which would > >>>>>>>>>>>>>>> require > >>>>>>>>>>>>>>> duplicating some files like `lib/actions.c`). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Do not pursue this. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Listing it here because it's on the "con" side of things. :) I > >>>>>>>>> wonder > >>>>>>>>>>>>>> if we'll end up duplicating all OVS actions into OVN logical > >>>>>>>>>>>>>> flow > >>>>>>>>> actions. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Actually that's my goal. Instead of using OpenFlow rules > >>>>>>>>>>>>> directly, a > >>>>>>>>>>>>> user can express > >>>>>>>>>>>>> their pipeline as logical flows and not worry about the > >>>>>>>>>>>>> intricacies of > >>>>>>>>>>>>> openflow syntax. > >>>>>>>>>>>>> It does add another layer of abstraction for sure. > >>>>> > >>>>> > >>>>> With maintenance cost in mind, we definitively prefer hosting this in > >>>>> the main repository, and I think it fits nicely in there. > >>>>> > >>>>> -- > >>>>> Frode Nordahl > >>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks > >>>>>>>>>>>>> Numan > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I welcome your thoughts and would like to know if other OVN > >>>>>>>>>>>>>>> users > >>>>>>>>> have > >>>>>>>>>>>>>>> similar requirements. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> A proof-of-concept is available here: > >>>>>>>>>>>>>>> > >>>>>>>>> https://github.com/numansiddique/ovn/tree/ > >>>>>>>>> provider_controller_support. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> If there is a consensus in pursuing this further, I'll > >>>>>>>>>>>>>>> work on > >>>>>>>>>>>>>>> refining the patches and submit them as RFC to start with. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In general I have no objections to an RFC. (CC the rest of the > >>>>>>>>> maintainers). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> Numan > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>> Dumitru > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> Ales > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>> > >>>> Thanks, > >>>> Dumitru > >>>> > >>> > >> > > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
