<div dir="ltr">+1 to NACK on the FFE. Let's do this first thing in Icehouse :)</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 6, 2013 at 10:06 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Sep 06, 2013 at 09:49:18AM -0400, Russell Bryant wrote:<br>
> On 09/06/2013 08:30 AM, Mark McLoughlin wrote:<br>
> > On Fri, 2013-09-06 at 10:59 +0200, Thierry Carrez wrote:<br>
> >> Mark McLoughlin wrote:<br>
> >>> I'd like to request a feature freeze exception for the final (and<br>
> >>> admittedly the largest) patch in the series of 40 patches to port Nova<br>
> >>> to oslo.messaging:<br>
> >>><br>
> >>> <a href="https://review.openstack.org/39929" target="_blank">https://review.openstack.org/39929</a><br>
> >><br>
> >> I'm generally adverse to granting feature freeze exceptions to code<br>
> >> refactoring: the user benefit of having them in the release is<br>
> >> inexistent, while they introduce some risk by changing deep code<br>
> >> relatively late in the cycle. That's why I prefer those to be targeted<br>
> >> to earlier development milestones, this avoids having to make hard calls<br>
> >> once all the work is done and almost completed.<br>
> ><br>
> > Yes, absolutely understood.<br>
> ><br>
> > To be clear - while I think there's a strong case for an exception here,<br>
> > I am very close to this, so I would be cool with a denial of this<br>
> > request.<br>
> ><br>
> >> That said, if the risk is under control and the patch is ready to merge,<br>
> >> I'm fine with this as long as there is some other benefits in having it<br>
> >> *in* the release rather than landed first thing in icehouse.<br>
> >><br>
> >> Would having it *in* the release facilitate stable/havana branch<br>
> >> maintenance, for example ?<br>
> >><br>
> >>> While this change doesn't provide any immediate user-visible benefit, it<br>
> >>> would be massively helpful in maintaining momentum behind the effort all<br>
> >>> through the Havana cycle to move the RPC code from oslo-incubator into a<br>
> >>> library.<br>
> >><br>
> >> Could you expand on why this would be a lot more helpful to have it in<br>
> >> the release rather than early in icehouse ?<br>
> >><br>
> >> And to have all cards on the table, how much sense would the alternative<br>
> >> make (i.e. not land this final patch while a lot of this feature code<br>
> >> has already been merged) ?<br>
> ><br>
> > If the patch was merged now, while it's not a user-visible feature<br>
> > per-se, I think oslo.messaging is something we would celebrate in the<br>
> > Havana release e.g.<br>
> ><br>
> > While OpenStack continues to add new projects and developers while,<br>
> > in parallel, aggressively takes steps to enable the project to scale.<br>
> > The oslo.messaging library added in the Havana release is an example<br>
> > of where code which was previously copied and pasted between projects<br>
> > and has now been re-factored out into a shared library with a clean<br>
> > API. This library will provide a structured way for OpenStack<br>
> > projects to collaborate on adopting new messaging patterns and<br>
> > features without the disruption of incompatible API changes nor the<br>
> > pain of keeping copied and pasted code in sync.<br>
> ><br>
> > Obviously, as Oslo PTL, I think this is an important theme that we<br>
> > should continue to emphasise and build momentum around. The messaging<br>
> > library is by far the most significant example so far of how this<br>
> > process of creating libraries can be effective. Nova using the library<br>
> > in the Havana release would (IMHO) be the signal that this process is<br>
> > working and hopefully inspire others to take a similar approach with<br>
> > other chunks of common code.<br>
> ><br>
> > Conversely, if we delayed merging this code until Icehouse, I think it<br>
> > would leave somewhat of a question mark hanging over oslo.messaging and<br>
> > Oslo going into the summit:<br>
> ><br>
> > Is this oslo.messaging thing for real? Or will it be abandoned and we<br>
> > need to continue with the oslo-incubator RPC code? Why is it taking so<br>
> > long to create these libraries? This sucks!<br>
<br>
</div></div>I think you're under-selling yourself here. As an interested 3rd party to<br>
oslo development, that certainly isn't my impression of what has happened<br>
with oslo.messaging development until this point.<br>
<br>
I think you have a pretty credible story to tell about the work done to<br>
get oslo.messaging to where it is now for Havana, even without it being<br>
used by Nova & don't think anyone could credibly claim it is dead or<br>
moving too slowly. Reusable library design is hard to get right & takes<br>
time if you want to support a stable API long term.<br>
<br>
I don't know about your non-Nova plans, but doing the final conversion in<br>
Icehouse timeframe may give you time in which to convert other openstack<br>
projects to oslo.messaging at the same time, so we would have everything<br>
aligned at once.<br>
<div class="im"><br>
> > That's all very meta, I know. But I do really believe making progress<br>
> > with Oslo libraries is important for OpenStack long-term. While it's not<br>
> > a user-visible benefit per-se, I do think this work benefits the project<br>
> > broadly and is also something worth marketing.<br>
> ><br>
> > We measure our progress in terms of what we achieved in each release<br>
> > cycle. I think we've made great progress on oslo.messaging in Havana,<br>
> > but unless a project uses it in the release it won't be something we<br>
> > really celebrate until Icehouse.<br>
<br>
</div>I can understand where you're coming from here, but if we push oslo.messaging<br>
into Nova and it caused stability problems, then I think any celebration you<br>
might have, could easily reverse, to be a negative impression of oslo.messaging<br>
which would be a shame for both nova & oslo.<br>
<div class="im"><br>
> > If we agree the risk is manageable, I hope the above shows there is<br>
> > ample benefit in comparison to the risk.<br>
><br>
> I'm actually quite impressed that we were able to merge as much of this<br>
> as we did given how big it was and that it started mid-h3. If fewer<br>
> patches had merged, waiting to Icehouse would look a lot more painful.<br>
><br>
> I'm not sure that Nova gains a whole lot by merging this now vs in a few<br>
> weeks. The arguments for merging seem to be less technical, and more<br>
> around project momentum. I totally get that and would like to support<br>
> it. I wonder though, what if we merged this as soon as master opens up<br>
> for Icehouse development, which would be before the summit? If we went<br>
> that route, the project momentum would still be there going into the<br>
> summit. There should be less of a question of "if" around<br>
> oslo.messaging, and more about how and when you can get the rest of the<br>
> projects converted to use it.<br>
><br>
> I propose a NACK on the FFE, and instead going with the above plan.<br>
<br>
</div>I'm inclined to agree. I don't see the compelling user relevant reason<br>
why Nova needs to switch to olso.messaging right now, with the risk<br>
that implies, over waiting till Icehouse dev starts.<br>
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888">--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Davanum Srinivas :: <a href="http://davanum.wordpress.com">http://davanum.wordpress.com</a>
</div>