Open Stack

On 4 September 2014 23:48, Russell Bryant <rbryant at redhat.com> wrote:
> On 09/04/2014 06:24 AM, Daniel P. Berrange wrote:
>> Position statement
>> ==================
>>
>> Over the past year I've increasingly come to the conclusion that
>> Nova is heading for (or probably already at) a major crisis. If
>> steps are not taken to avert this, the project is likely to loose
>> a non-trivial amount of talent, both regular code contributors and
>> core team members. That includes myself. This is not good for
>> Nova's long term health and so should be of concern to anyone
>> involved in Nova and OpenStack.
>>
>> For those who don't want to read the whole mail, the executive
>> summary is that the nova-core team is an unfixable bottleneck
>> in our development process with our current project structure.
>> The only way I see to remove the bottleneck is to split the virt
>> drivers out of tree and let them all have their own core teams
>> in their area of code, leaving current nova core to focus on
>> all the common code outside the virt driver impls. I, now, none
>> the less urge people to read the whole mail.
>
> Fantastic write-up.  I can't +1 enough the problem statement, which I
> think you've done a nice job of framing.  We've taken steps to try to
> improve this, but none of them have been big enough.  I feel we've
> reached a tipping point.  I think many others do too, and several
> proposals being discussed all seem rooted in this same core issue.

+1

I totally agree we need to split Nova up further, there just didn't
seem to be the support for this before now.

Not yet sure the virt drivers are the best split, but we already have
sub-teams ready to take them on, so it will probably work for that
reason.

> If we ignored gerrit for a moment, is rapid increase in splitting out
> components the ideal workflow?  Would we be better off finding a way to
> finally just implement a model more like the Linux kernel with
> sub-system maintainers and pull requests to a top-level tree?  Maybe.
> I'm not convinced that split of repos is obviously better.

I was thinking along similar lines.

Regardless of that, we should try this for Kilo.

If it feels like we are getting too much driver divergence, and
tempest is not keeping everyone inline, the community is fragmenting
and no one is working on the core of nova, then we might have to think
about an alternative plan for L, including bringing the drivers back
in tree.

At least the separate repos will help us firm up the interfaces, which
I think is a good thing.

I worry about what it means to test a feature in "nova common, nova
api, or nova core" or whatever we call it, if there are no virt
drivers in tree. To some extent we might want to improve the fake virt
driver for some in-tree functional tests anyways. But thats a separate
discussion.

> I don't think we can afford to wait much longer without drastic change,
> so let's make it happen.

+1

But I do think we should try and go further...

Scheduler: I think we need to split out the scheduler with a similar
level of urgency. We keep blocking features on the split, because we
know we don't have the review bandwidth to deal with them. Right now I
am talking about a compute related scheduler in the compute program,
that might evolve to worry about other services at a later date.

Nova-network: Maybe there isn't a big enough community to support this
right now, but we need to actually delete this, or pull it out of
nova-core.

API: I suspect we might want to also look at splitting out the API
from Nova common too. This one is a slightly more drastic, and needs
more pre-split work (and is very related to making cells a first class
concept), but I am still battling with that inside my head.

Oslo: I suspect we may need to do something around the virt utilities,
so they are easy to share, but there are probably other opportunities
too.

Thanks,
John