Open Stack

On Fri, Sep 06, 2013 at 09:49:18AM -0400, Russell Bryant wrote:
> 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!

I think you're under-selling yourself here. As an interested 3rd party to
oslo development, that certainly isn't my impression of what has happened
with oslo.messaging development until this point.

I think you have a pretty credible story to tell about the work done to
get oslo.messaging to where it is now for Havana, even without it being
used by Nova & don't think anyone could credibly claim it is dead or
moving too slowly. Reusable library design is hard to get right & takes
time if you want to support a stable API long term. 

I don't know about your non-Nova plans, but doing the final conversion in
Icehouse timeframe may give you time in which to convert other openstack
projects to oslo.messaging at the same time, so we would have everything
aligned at once.

> > 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.

I can understand where you're coming from here, but if we push oslo.messaging
into Nova and it caused stability problems, then I think any celebration you
might have, could easily reverse, to be a negative impression of oslo.messaging
which would be a shame for both nova & oslo.

> > 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.

I'm inclined to agree. I don't see the compelling user relevant reason
why Nova needs to switch to olso.messaging right now, with the risk
that implies, over waiting till Icehouse dev starts.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|