Open Stack

On Fri, Apr 17, 2015 at 12:16:25PM -0400, Jay Pipes wrote:
> 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.

Yes, that's exactly the set of tasks that is going to be hidden from Nova
in the work Brent is doing to enable "scripts". Ultimately all the plug/unplug
methods in vif.py should go away, and Neutron will just pass over the name of
a script to execute at plug & unplug stages. So all the vif.py file in libvirt
will need todo is invoke the nominated script at the right time, and build the
libvirt XML config. All the "business logic" will be entirely under the control
of the Neutron maintainer.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|