True. For example, the infiniband passthrough blueprint might need port type info from neutron->nova?
Thanks, Kevin ________________________________________ From: Neil Jerram [neil.jer...@metaswitch.com] Sent: Friday, April 17, 2015 9:44 AM To: openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev