Open Stack

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.

Thanks,
Mark.