Vlan aware VM - assign FIP to port which configured as "subport" is irrelevant

[Alex Stafeyev]

osp10
We crated:
External network.
2 internal networks- net1 and net2.
Port from each network - port1 and port2.
Trunk, configured with port1.
Trunk sub-port configured with port2.
Floating ip.

We booted a VM with port1 port and configured on the VM eth0 with eth0.VLAN sub interface, matches port2 configuration.

We assigned FIP to port2 - no connectivity to VM via port 2.

Cause:
Due to 1 GW on the VM via eth0 ( untagged ), all tagged requests that need GW go to the untagged GW- which fails the connectivity.
This behavior is correct.
So there is no meaning to assign fip to neutron port which was configured as trunk subport.

We should block this option.

[Armando Migliaccio (armando-migliaccio)]

I feel we can address these corner cases with a bit of a user education. Knowing how to set up a trunk and what subports are used for, no user would try to access/fiddle with them directly if not by accident. Thinking about how to address this in code, we would need some hook that would block certain operations from occurring, though if we are not careful we can create more damage than good :).

We should warn users [1] not to directly handle subports until we can come up with a good solution, if a solution is indeed required for such edge cases.

[1] https://review.openstack.org/#/c/361776/

[Armando Migliaccio (armando-migliaccio)]

Bear in mind that this report falls under of the category of issues that stem from the user unintentionally (or intentionally, but ignoring how to use the overall feature) doing something with subports when they are not meant to be targeted directly. I would expect other conditions where the outcome of a port action is indeed undefined.

[Jakub Libosvar (libosvar)]

Isn't this the same scenario as if user would add to an instance two nics from different networks and assigns floating ips to both? If we want treat this as a bug then I don't think it should be treated as a bug in trunk feature as this has a larger scope - assigning floating ip to an instance that already has a floating ip.

[Alex Stafeyev (astafeye)]

It is as Jakub says. The network functionality is correct, so the thing to do , if not to block this option, is indeed to make sure users know that the traffic can not get to the tagged networks via FIP without implementing static routes manually.

[Armando Migliaccio (armando-migliaccio)]

I am having second thoughts on whether this should be blocked, and if not whether there is anything required from the platform in order to set up FIP connectivity to the subport. If the VM is running container workloads, the use case makes sense and requiring manual static route settings may be painful, but what about a VNF?

[Kevin Benton (kevinbenton)]

This shouldn't be blocked. Consider the case of running a bunch of containers in a VM. Each one can have the IP of the subport and its correct gateway corresponding to the network the subport is attached to (each can even use DHCP). A floating IP for each container is perfectly valid in this case.

[Armando Migliaccio (armando-migliaccio)]

@kevin: duh!

[Kevin Benton (kevinbenton)]

Whoops, sorry armax I didn't see your comment.

[Toni Freger (tfreger)]

Assaf, considering Kevin's comment, it seems that we need to change our entire focus to the containers scenario instead of multiple interfaces on the same VM, since it will be less practical or even not practical at all.