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
__________________________________________________________________________
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
