…
The problem.
------------
There are use cases, when it us needed to attach vnic to some specific
network interface instead of br-int.
For example, working with trunk ports, it is better to attach vnic to a
specific trunk bridge, and the bridge add to br-int. But it doesn't fit
in the current design.
There are several possible ways to solve the issue:
1. make the user responsible to pass the ready-to-use port to nova, so
nova will not care about adding port by libvirt to the bridge
2. make the neutron service synchronously call the agent to create the
required interface, e.g. the trunk bridge.
3. make the neutron somehow to delay vif plug
4. make the nova to create the required port
Also two hack-like alternatives:
5. use not another interface like the trunk bridge, and instead install
another flow table
6. intercept vnic plug, and forcibly reattach it to an on-demand created
interface
The 5. leads us to problems with mac-learning. The 6. is a pure hack,
that will cause issues with literally everything, like migration etc.
The 1. is not a solution sensu stricto. The 2. has the scalability
issue, effectively turning the neutron to be synchronous across all the
cluster in that case.
The 3. and 4. sound more reasonable, but 3. is not so clear (for me) how
to do, and 4. impacts the nova.
…
And there is a solution, that can be used in that case as well, the
binding negotiation, see references below.
…
The question
------------
I would like to see your opinions, how it could be managed. I believe I
could miss something. Thanks for comments.
…
References
----------
https://review.openstack.org/#/c/190917/7/specs/mitaka/approved/nova-neutron-binding-negotiation.rst
https://review.openstack.org/#/c/213644/1/specs/mitaka/approved/trunk-port.rst
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
