[openstack-dev] [nova][neutron] ports management

Peter V. Saveliev peter at svinota.eu
Tue Oct 6 15:52:39 UTC 2015


…


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



More information about the OpenStack-dev mailing list