[openstack-dev] [Nova] Things to tackle in Liberty

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri Apr 17 18:02:06 UTC 2015

True. For example, the infiniband passthrough blueprint might need port type info from neutron->nova?

From: Neil Jerram [Neil.Jerram at metaswitch.com]
Sent: Friday, April 17, 2015 9:44 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Things to tackle in Liberty

On 17/04/15 17:24, Daniel P. Berrange wrote:
> 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.

Yes; but, as I commented on the spec earlier today, I don't think the
vif-plugin-script work as it stands quite gets us there.  We also still
need either a set of base VIF types in Nova - e.g., in the libvirt case,
to control whether the generated XML is <interface type='ethernet' ...>
or <interface type='bridge' ...> - or some equivalently generic
information that is passed from Neutron to allow Nova to generate the
required XML (or equivalent for other hypervisors).


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list