[openstack-dev] [Nova] Things to tackle in Liberty
mriedem at linux.vnet.ibm.com
Thu Apr 9 23:22:59 UTC 2015
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 [...]
>> OMG, this is still a thing. We need to actually work out what we’re
>> doing here, and then do it. [...]
>> 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,
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 Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev