Open Stack

On 4/9/2015 8:56 AM, Neil Jerram wrote:
> On 08/04/15 22:07, Michael Still wrote:
>
>> priorities and specs
>> ===============
>>
>> I think the current spec process is starting to work well for us, and
>> that priorities was a success. We should continue with specs, but with
>> an attempt to analyse why so many approved specs don’t land [...]
>
>> nova-net
>> =======
>>
>> OMG, this is still a thing. We need to actually work out what we’re
>> doing here, and then do it. [...]
>
>> conclusion
>> ========
>>
>> I make no claim that my list is exhaustive. What else do you think we
>> should be tackling in Liberty?
>
> Something kind of related to two of the strands above, from the point of
> view of someone who had an approved networking-related Nova spec that
> failed to land for Kilo...
>
> Basically, should Nova try harder to get out of the networking business?
>   Currently the situation is that OpenStack networking experimentation
> is mostly in Neutron (as I assume it should be) but also often requires
> changes to the VIF type code in Nova.  Should we try to close off that
> situation, I would guess through some structural solution that puts all
> the required code changes firmly into Neutron's domain?

Yes, this isn't just Neutron, it's also storage backends with Cinder, 
see nova.virt.libvirt.volume.

At one point in this release I tried to wrap my head around why we have 
all of this VIF plugging gorp inside nova and requires a nova change to 
enable neutron plugins.  This all happened before I was working on the 
project, but my takeaway was this was how nova got neutron up and 
running at the time with the way nova was architected for nova-network, 
but is like fitting a square peg in a round hole, i.e. the virt driver 
has to do something locally so the neutron agent picks up that change 
and tells the neutron server and meanwhile nova is waiting on the vif 
plugging callback event from neutron so it can continue with the server 
build request (and that's only the libvirt driver).  I'm not really sure 
why nova can't simply call a neutron API to do the plug and then wait 
for a response that it's done, but leave all of the messy neutron 
plugin-specific binding stuff in neutron and abstract it away from nova. 
  Same goes for cinder and connecting/disconnecting volumes.

But I'm naive, so just my 2 cents here.

>
> I don't want to prejudge what the solution might be.  My point here is
> to suggest discussing and deciding whether this could be a worthwhile
> priority.  If it sounds of interest, I could add something to the
> etherpad for Nova design session ideas.
>
> (I appreciate that the nova-net question is way bigger and more
> practically important overall than my specific point about the VIF type
> code.  However it is possible that the VIF type code contributes to a
> continuing lack of clarity about where networking function lies in
> OpenStack.)
>
> 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

-- 

Thanks,

Matt Riedemann