Open Stack

Hi Rodolfo,

I agree with you, my initial idea with this thread was exactly what we are
doing, debating problems and possible solutions for interconnecting
workloads using unmanaged dynamic router resources. Thank you for being
engaged with this!
I'm sorry if the strategy wasn't presented clearly, let me talk about it
then.

Imagine we have a tenant on OpenStack, and this client has all the
resources created by OpenStack itself
1 - Tenant OpenStack project
2 - Tenant self-service network
3 - Tenant self-service subnet - e.g. 10.0.0.0/24
4 - Security groups
5 - Maybe FIPs
6 - Tenant Logical Router
7 - Tenant Logical Router Ports:  1.  external network (provider/default
gw) ;   2. internal network (self-service subnet)
8 - Tenant VMs - some VMs on the self-service subnet 10.0.0.0/24

Now that same tenant expects to connect these VMs with another deployment
in the same region - High Availability.

Option 1 - Floating IPs -> it's not a good option
Option 2 - OVN-IC - L3 routing between self-service networks   :)

What's the strategy? connect the Tenant Logical Router with the TS of the
OVN-IC.

Creation steps:
1. Create a transit switch in the OVN-IC-NB
2. In each OpenStack / Neutron:
   a. Create a new Logical_Router_Port (externally managed) on the Tenant
Logical Router and link this port with the TS.

What is the point here, as Felix comments: even with the creation of the
special network type, it will still be necessary to filter learned
resources.
"   a. Ignore all resources where `external_ids` does not contain any key
      starting with `neutron`."

So, from my perspective:
Neutron changes for the [RFE] unmanaged dynamic router resources - OVN
   b. Ignore specific resources as defined by individual rules:
      I. ignore all Logical_Router_Ports  where `external_ids` does not
contain any key
      starting with `neutron`.
      II. ignore all Logical_Router_Static_Route where `external_ids` does
not contain any key
      starting with `neutron`.


We have already tested this and it is enough for interconnect to work in
multi-tenant scenarios, and with the router connected to a generic external
network provider (where all other tenants are connected).

That is, the Logical Router was created by Neutron, so it can decide to
learn dynamic routes and ignore external interconnect Logical_Router_Ports.

BTW: Felix, the transit switch will learn remote Logical_Switch_Ports ports
automatically via OVN-NB, in this case these ports were not created by
Neutron and would need more special treatment to skip these resources.

Note: about creating a new external provider network type, I already
expressed my arguments about the multi tenant case and the need to create
more resources to have this together with the default gw. If it were
possible to have this in the same Logical_router tenant, I mean, use two
external networks on the same Router: here we would have a lot of gain in
my perspective

Regards,
Roberto



Em ter., 18 de jul. de 2023 às 09:40, Felix Huettner
<felix.huettner at mail.schwarz> escreveu:

> 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>.
>

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230718/c4d86e0d/attachment-0001.htm>