[ml2][ovs] allow multiple physical networks map to one physical ovs bridge

[LIU Yulong]

In real cloud production environment, there are many hosts, which can access external network, which may not. Some have enough NICs to work for different networks, while some are lack of NICs.

For instance, an external network, provider:network_type is ``vlan``, provider:physical_network is ``external``, provider:segmentation_id is ``4000``.

While tenant network, provider:network_type is ``vlan``, provider:physical_network is ``user``, provider:segmentation_id is ``1000-3000``.

So for neutron's limitation, in one single host, you have to add two ovs-bridges which are mapping external->br-ex, user->br-usr. And br-ex adds physical port eth0, br-usr adds eth1.

But, in real world, these vlans can work in same physical nic, and physical hosts may be lack of NICs, which means, Neutron should allow set bridge mapping like this:
{"external": br-vlan, "user": br-vlan}

Then, for those hosts with only one NIC (or one bond NIC), can work for both physical types of network.

You may say, may be we can set one network with two types of "provider:physical_network". One single network is currently type uniq. This will be a bit more complicated than the former solution. This needs not only neutron-server side DB model changes, but also agent side change. While the former may only need agent side change to allow set that mappings.

Any ideas?

[Oleg Bondarev (obondarev)]

Thus "physical_network" would effectively mean "logical" network. Doesn't it contradict with "physical network" meaning? IMO it will bring inconsistency into already complex provider networks logic.

[LIU Yulong (dragon889)]

It is still "logical", but some "logical" will work on same physical "nic" to outside world. The final mapping illustrates the isolation of "logical":
{"external": br-vlan, "user": br-vlan}

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/820006

[Lajos Katona (lajos-katona)]

We have similar usecases so I understand the need for such thing, but I would go for an RFE, and discuss it on drivers meeting. Perhaps more discussion is needed as the physnet (what is physnet?) and bridgme mappings and such things are deeply built into neutron.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello:

There are several considerations to be done in this RFE. For example limiting the vlan ranges of the networks or redesign the physical bridge flows (now we have two ports only) to avoid sending traffic from one provider network to other. I didn't find yet any issue related to the FW but this should be considered too.

And of course, the documentation.

Regards.

[Lajos Katona (lajos-katona)]

On today's drivers meeting we discussed this bug:
https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-12-03-14.01.log.html#l-15

The conclusion was to keep the current 1 Nic - 1 bridge - 1 physnet mapping/relation.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "liuyulong <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/820006
Reason: Restore if someday we want this.