Open Stack

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

Thanks,
Kevin
________________________________________
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).

Regards,
        Neil

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev