[openstack-dev] [Nova][Quantum] Move quantum port creation to nova-api

Robert Kukura rkukura at redhat.com
Thu May 16 19:47:43 UTC 2013


On 05/16/2013 02:40 PM, Mike Wilson wrote:
> 
> 
> 
> On Thu, May 16, 2013 at 12:28 PM, Robert Kukura <rkukura at redhat.com
> <mailto:rkukura at redhat.com>> wrote:
> 
>     >
>     > @Mike - I think we'd still want to leave nova-compute to create
>     the tap
>     > interfaces and sticking  external-ids on them though.
> 
>     It also seems nova-compute should call port-update to set
>     binding:host_id and then use the returned binding:vif_type, since the
>     vif_type might vary depending on the host, at least with ml2. The Arista
>     top-of-rack switch hardware driver functionality also depends on the
>     binding:host_id being set.
> 
>     -Bob
> 
> 
> Hmmm, is that really nova-compute's job? Again, that seems to be the
> networking abstraction's job to me. We have all these quantum agents,
> they have the device_id (instance_uuid). Why not have a quantum
> component (agent maybe?) query nova for the host_id and then it calls
> port-update?

I believe this is the final step of an attempt to cleanup the
abstraction between nova and quantum. The idea is to have quantum decide
on the VIF driver, rather than having this knowledge built into the nova
configuration.

In some cases, quantum will need to know what host the port is being
bound on so it can determine which VIF driver to use (possibly based on
what agent is running on that host). Also, a quantum L2 agent (if there
is one) cannot notice the that the port is binding bound until after the
VIF driver has been selected and done its thing.

The nova code for this has been in review for a while, but may have
expired. Gerrit is offline at the moment, so I can't search for it.

-Bob

> 
> -Mike
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list