Open Stack

On 6 March 2014 11:31, Sean Dague <sean at dague.net> wrote:
> On 03/06/2014 05:51 AM, John Garbutt wrote:
>> On 5 March 2014 15:02, Russell Bryant <rbryant at redhat.com> wrote:
>>> Nova is now feature frozen for the Icehouse release.  Patches for
>>> blueprints not already merged will need a feature freeze exception (FFE)
>>> to be considered for Icehouse.
>>>
>>> In addition to evaluation the request in terms of risks and benefits, I
>>> would like to require that every FFE be sponsored by two members of
>>> nova-core.  This is to ensure that there are reviewers willing to review
>>> the code in a timely manner so that we can exclusively focus on bug
>>> fixes as soon as possible.
>>
>> To help avoid adding too many FFE and not getting enough bug fixing done...
>>
>> I have a proposal to try and get many of the blueprints that just
>> missed getting into Icehouse merged in early Juno, ideally before the
>> Summit.
>>
>> For the interested, here are blueprints that met the proposal deadline
>> but didn't make Icehouse-3:
>> * API (v2) blueprints: 8
>> * VMware: 7
>> * Scheduler blueprints: 7  (two were partially completed in Icehouse)
>> * Others: around another 7
>>
>> Making an effort to get these merged in Juno-1, and ideally before the
>> summit, seems a fair thing to do.
>>
>> Once Juno opens, if submitters get their blueprint patches rebased and
>> ready to review by two weeks before the summit, I propose we try to
>> give them (where possible, and where it makes sense) at least medium
>> priority, at least until after the summit.
>>
>> If we get too many takers, that might need some "refinement". However,
>> looking at them, they all appear to be features that our users would
>> really benefit from.
>>
>> This probably means, all non-"top priority" items would then get low
>> priority in Juno-1. Currently tasks (at least the move to conductor
>> parts), the scheduler split and objects, seem like they will be the
>> other high priority items for Juno-1.
>>
>> This is all very rough, and subject to massive post-summit change, but
>> looking at the ones with their priority set, gives a rough idea of
>> what Juno-1 might look like:
>> https://launchpad.net/nova/+milestone/next
>>
>> Its just an idea. What do you all think?
>
> I think it's generally a good approach. I'll just caution that most of
> the core review team is burnt out hard by the end of the release, and
> really does need a breather. There is plenty of prep that needs to
> happen to summit, and it provides a pretty solid recharge.

True. Its probably unrealistic to get them merged before the summit.
But I still think its worth considering for Juno-1.

> In the past I think the biggest issue you saw blueprints miss two cycles
> in a row is their authors weren't working on them until milestone 2. So
> anything that's open and ready to go in Juno.

True.

Some had be to split up their patches so were really only ready for
review in March.

But some have been open much longer than that. Its just they kept
being at the bottom of the queue. I feel we need something to stop the
priority inversion.

> That being said, importance isn't a FIFO.

Agreed, but it seems most of them are quite useful, and a lot have
already been through a few review cycles.

> And with limited review time I
> question a ton of scheduler blueprints at the same time we're talking
> about a scheduler split. Because like it seems like it makes both things
> slower to try them at the same time (as there are a limited number of
> people here). So I think at least in this case scheduler really should
> be split then improve, or improve then split, and everyone interested in
> either side of that equation needs to be helping on both sides.
> Otherwise I think we'll see another do-over on the split again at the
> end of the Juno cycle.

Given the discussion at the mid-cylce meet up, I got the impression
are planning on splitting out the code more in nova, then
re-generating the gantt tree. Using the lessons learnt from the
current efforts to speed up things after the next regeneration.

Most of the scheduler blueprints don't look to impact the edges that
are likely to change the most, but I could be totally misjudging that.

John