Open Stack

On 17/04/15 17:16, 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.

I entirely agree on this big picture.  I think the disagreement (i.e. 
your -1) is just with some detail of my wording above; perhaps the "from 
within Nova"?

> 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"? :)

Just that we always need to respect back-compatibility.  Isn't that a 
normal assumption within OpenStack?  (Perhaps I didn't need to say it, 
then... :-))

Regards,
	Neil