Open Stack

On 09/06/2013 08:30 AM, Mark McLoughlin wrote:
> On Fri, 2013-09-06 at 10:59 +0200, Thierry Carrez wrote:
>> Mark McLoughlin wrote:
>>> I'd like to request a feature freeze exception for the final (and
>>> admittedly the largest) patch in the series of 40 patches to port Nova
>>> to oslo.messaging:
>>>
>>>   https://review.openstack.org/39929
>>
>> I'm generally adverse to granting feature freeze exceptions to code
>> refactoring: the user benefit of having them in the release is
>> inexistent, while they introduce some risk by changing deep code
>> relatively late in the cycle. That's why I prefer those to be targeted
>> to earlier development milestones, this avoids having to make hard calls
>> once all the work is done and almost completed.
> 
> Yes, absolutely understood.
> 
> To be clear - while I think there's a strong case for an exception here,
> I am very close to this, so I would be cool with a denial of this
> request.
> 
>> That said, if the risk is under control and the patch is ready to merge,
>> I'm fine with this as long as there is some other benefits in having it
>> *in* the release rather than landed first thing in icehouse.
>>
>> Would having it *in* the release facilitate stable/havana branch
>> maintenance, for example ?
>>
>>> While this change doesn't provide any immediate user-visible benefit, it
>>> would be massively helpful in maintaining momentum behind the effort all
>>> through the Havana cycle to move the RPC code from oslo-incubator into a
>>> library.
>>
>> Could you expand on why this would be a lot more helpful to have it in
>> the release rather than early in icehouse ?
>>
>> And to have all cards on the table, how much sense would the alternative
>> make (i.e. not land this final patch while a lot of this feature code
>> has already been merged) ?
> 
> If the patch was merged now, while it's not a user-visible feature
> per-se, I think oslo.messaging is something we would celebrate in the
> Havana release e.g.
> 
>   While OpenStack continues to add new projects and developers while, 
>   in parallel, aggressively takes steps to enable the project to scale. 
>   The oslo.messaging library added in the Havana release is an example 
>   of where code which was previously copied and pasted between projects 
>   and has now been re-factored out into a shared library with a clean 
>   API. This library will provide a structured way for OpenStack 
>   projects to collaborate on adopting new messaging patterns and 
>   features without the disruption of incompatible API changes nor the 
>   pain of keeping copied and pasted code in sync.
> 
> Obviously, as Oslo PTL, I think this is an important theme that we
> should continue to emphasise and build momentum around. The messaging
> library is by far the most significant example so far of how this
> process of creating libraries can be effective. Nova using the library
> in the Havana release would (IMHO) be the signal that this process is
> working and hopefully inspire others to take a similar approach with
> other chunks of common code.
> 
> Conversely, if we delayed merging this code until Icehouse, I think it
> would leave somewhat of a question mark hanging over oslo.messaging and
> Oslo going into the summit:
> 
>   Is this oslo.messaging thing for real? Or will it be abandoned and we
>   need to continue with the oslo-incubator RPC code? Why is it taking so
>   long to create these libraries? This sucks!
> 
> That's all very meta, I know. But I do really believe making progress
> with Oslo libraries is important for OpenStack long-term. While it's not
> a user-visible benefit per-se, I do think this work benefits the project
> broadly and is also something worth marketing.
> 
> We measure our progress in terms of what we achieved in each release
> cycle. I think we've made great progress on oslo.messaging in Havana,
> but unless a project uses it in the release it won't be something we
> really celebrate until Icehouse.
> 
> If we agree the risk is manageable, I hope the above shows there is
> ample benefit in comparison to the risk.

I'm actually quite impressed that we were able to merge as much of this
as we did given how big it was and that it started mid-h3.  If fewer
patches had merged, waiting to Icehouse would look a lot more painful.

I'm not sure that Nova gains a whole lot by merging this now vs in a few
weeks.  The arguments for merging seem to be less technical, and more
around project momentum.  I totally get that and would like to support
it.  I wonder though, what if we merged this as soon as master opens up
for Icehouse development, which would be before the summit?  If we went
that route, the project momentum would still be there going into the
summit.  There should be less of a question of "if" around
oslo.messaging, and more about how and when you can get the rest of the
projects converted to use it.

I propose a NACK on the FFE, and instead going with the above plan.

-- 
Russell Bryant