+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 <berra...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev