Open Stack

On 04/10/2015 11:48 AM, Neil Jerram wrote:
> What I imagine, though, is that the _source_ of the plugging information
> could move from Nova to Neutron, so that future plugging-related code
> changes are a matter for Neutron rather than for Nova.  The plugging
> would still _happen_ from within Nova, as directed by that information.

-1. One of the biggest problems I have with the current implementation 
for Nova VIF types is that stuff leaks improperly out of the Neutron 
API. Take a look at all the Contrail implementation specifics in here:

https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L551-L589

That belongs in the Neutron plugin/agent side of things. Nova should not 
need to know how to call the vrouter-port-control Contrail CLI command. 
That should be Neutron's domain -- and not the Neutron API, but instead 
the underlying L2 agent/plugin. Most of the port binding profile stuff 
that is returned by the Neutron API's primitives should never have been 
exposed by the Neutron API, in my opinion. There's just too much 
driver-implementation specifics in there.

> (For libvirt, I believe the required information would be the interface
> type and parameters to go into the libvirt XML, and then any further
> processing to do after that XML has been launched.  I believe the latter
> is covered by the vif-plug-script spec, but not the former.)

Agreed.

> However, on thinking this through, I see that this really is bound up
> with the wider question of nova-net / Neutron migration - because it
> obviously can't make sense for plugging information to come from Neutron
> if some people are not using Neutron at all for their networking.
>
> Stepping right back, though, is it agreed in principle that detailed
> networking code should move from Nova to Neutron, if that is possible
> while preserving all existing behaviours?  If it is agreed, that's
> something that I'd like to help with.

What precisely do you mean by "preserving all existing behaviours"? :)

-jay