Hi everyone, we will validate in the next weeks the idea i'll describe below. If it sounds feasible to us i would write up a spec for this for later implementation. Setup: 1. Two neutron setups with OVN 2. A OVN-IC setup not managed by any tooling (used manually) Target setup for a individual project +-------------------------------------+ | Transit Switch (ts1) | | 172.24.0.0/24 | +-------------------------------------+ | | +----------------+ +----------------+ | 172.24.0.10 | | 172.24.0.11 | | Router | | Router | | 192.168.0.1 | | 192.168.1.1 | +----------------+ +----------------+ | | +----------------+ +----------------+ | Network | | Network | | 192.168.0.0/24 | | 192.168.1.0/24 | +----------------+ +----------------+ | | +----------------+ +----------------+ | VM | | VM | | 192.168.0.10 | | 192.168.1.10 | +----------------+ +----------------+ Main creation workflow of a interconnected network: 1. Create a transit switch in the OVN-IC-NB 2. In each neutron: a. Create a new provider network that maps to the transit switch. E.g. using `--provider-network-type ovn-ic --provider-phyiscal-network ts1` b. Create the internal network and router as always and attach the router to the internal network and the provider network Changes needed in Neutron (from my perspective): 1. Neutron must not touch the resources created by OVN-IC. This might be done using two options: a. Ignore all resources where `external_ids` does not contain any key starting with `neutron`. b. Ignore specific resources as defined by individual rules: I. ignore all Logical_Router that contain `other_config:interconn-ts` II. ignore all Logical_Router_Static_Route that contain `external_ids:ic-learned-route` 2. Neutron must allow OVN-IC transit switches to be treated as external networks. AFAIK this should work in the same way as creating any kind of OVN network (so Logical_Switch), but just importing an existing Logical_Switch.
From my perspective with these two changes we should be good to interconnect two neutron setups with probably minimal changes needed. This is because OVN-IC would only touch the transit switch (which looks in the Northbound like a regular Logical_Switch). All other resources would still be managed by neutron and work as they do now.
I will get back to this discussion and (if appropriate) provide a spec or this idea, once we had time to validate this on our side (which will take some weeks). Thanks Felix On Tue, Jul 18, 2023 at 01:23:27PM +0200, Rodolfo Alonso Hernandez wrote:
Ok, this is being tortuous. First of all: define a strategy. If you are going to create the resources in Neutron, define how. I've provided a way to do this, find a formal strategy to ground it.
Second: (again) try to find a connection between resources, if you are going to use the strategy of creating the resources in Neutron. The "Logical_Router_Static_Route" belongs to a router univocally. If that router has been created by OpenStack, then you can modify the DB sync method to consider learned routes too.
In order to do this, you'll need a set of resources that are going to be needed in Neutron, the OVN counterparts and other resources (like "Logical_Router_Static_Route") that will be added and will be present in OVN and not in Neutron DB. Also you'll need to know how to relate all of them. Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail.
Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>. This e-mail may contain confidential content and is intended only for the specified recipient/s. If you are not the intended recipient, please inform the sender immediately and delete this e-mail. Information on data protection can be found here<https://www.datenschutz.schwarz>.