Open Stack

+1 to NACK on the FFE. Let's do this first thing in Icehouse :)


On Fri, Sep 6, 2013 at 10:06 AM, Daniel P. Berrange <berrange at redhat.com>wrote:

> 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:|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130906/e4d6ee4c/attachment.html>