Open Stack

Em qua., 19 de jul. de 2023 às 04:57, Rodolfo Alonso Hernandez <
ralonsoh at redhat.com> escreveu:

> Before that you need to explain why you need multiple external network
> ports and why cannot be solved with the current architecture Neutron is
> providing.
>

I and maybe others need this because Neutron's networking backend doesn't
have infinite resources. Although the architecture allows for adding a new
Logical_Router and configuring static routes, etc... This means consuming
more resources on the SDN backend.

So the problem here would be scalability: each tenant would need 2 routers
to do the work of only 1. In addition to the set of additional LRP's,
LSP's, Static Routes that the backend would need to configure. For a few
tenants this would be fine, but when we talk about thousands, this question
is very relevant.

ML2/OVN, for example, limits backend resources according to the OVN version
(each one has its scale limitations), in Ussuri's OVN 20.03 (we can't
create more than 600 routers and 400k openflow flows without triggering
config timeouts - ovn-controller/openvswitch recompute snowball)... in
Yoga's OVN 22.03 the numbers are a little better, but we also have
limits... Dedicating more resources to doing this would be a waste of
infrastructure.


>
> On Tue, Jul 18, 2023 at 3:52 PM Roberto Bartzen Acosta <
> roberto.acosta at luizalabs.com> wrote:
>
>>
>> Would it be possible to implement multiple external network ports on the
>> same router?
>>
>> It is not the same case of multi-homing [1], in the case of OVN-IC there
>> are no symmetric internet routes....
>> [1] https://review.opendev.org/c/openstack/neutron/+/874199
>>
>> Basically an external port for ovn-ic doesn't have SNAT!
>>
>> Could this be done Rodolfo? What would be the effort/implications?
>>
>> If possible, we can integrate everything we are discussing in terms of
>> solutions into a single reference design.
>>
>>
>> Em ter., 18 de jul. de 2023 às 10:20, Roberto Bartzen Acosta <
>> roberto.acosta at luizalabs.com> escreveu:
>>
>>> 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’.*
>>
>

-- 




_‘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/20230719/369ea73e/attachment-0001.htm>