On Wed, Aug 20, 2014 at 08:33:31AM -0400, Jay Pipes wrote: > On 08/20/2014 04:48 AM, Nikola Đipanov wrote: > >On 08/20/2014 08:27 AM, Joe Gordon wrote: > >>On Aug 19, 2014 10:45 AM, "Day, Phil" <philip....@hp.com > >><mailto:philip....@hp.com>> wrote: > >>> > >>>>-----Original Message----- > >>>>From: Nikola Đipanov [mailto:ndipa...@redhat.com > >><mailto:ndipa...@redhat.com>] > >>>>Sent: 19 August 2014 17:50 > >>>>To: email@example.com > >><mailto:firstname.lastname@example.org> > >>>>Subject: Re: [openstack-dev] [Nova] Scheduler split wrt Extensible > >>Resource > >>>>Tracking > >>>> > >>>>On 08/19/2014 06:39 PM, Sylvain Bauza wrote: > >>>>>On the other hand, ERT discussion is decoupled from the scheduler > >>>>>split discussion and will be delayed until Extensible Resource Tracker > >>>>>owner (Paul Murray) is back from vacation. > >>>>>In the mean time, we're considering new patches using ERT as > >>>>>non-acceptable, at least until a decision is made about ERT. > >>>>> > >>>> > >>>>Even though this was not officially agreed I think this is the least > >>we can do > >>>>under the circumstances. > >>>> > >>>>A reminder that a revert proposal is up for review still, and I > >>consider it fair > >>>>game to approve, although it would be great if we could hear from > >>Paul first: > >>>> > >>>> https://review.openstack.org/115218 > >>> > >>>Given the general consensus seemed to be to wait some before deciding > >>what to do here, isn't putting the revert patch up for approval a tad > >>premature ? > > > >There was a recent discussion about reverting patches, and from that > >(but not only) my understanding is that we should revert whenever in doubt. > > Right. > > http://lists.openstack.org/pipermail/openstack-dev/2014-August/042728.html > > >Putting the patch back in is easy, and if proven wrong I'd be the first > >to +2 it. As scary as they sound - I don't think reverts are a big deal. > > Neither do I. I think it's more appropriate to revert quickly and then add > it back after any discussions, per the above revert policy. > > >>> > >>>The RT may be not able to cope with all of the new and more complex > >>resource types we're now trying to schedule, and so it's not surprising > >>that the ERT can't fix that. It does however address some specific use > >>cases that the current RT can't cope with, the spec had a pretty > >>through review under the new process, and was discussed during the last > >>2 design summits. It worries me that we're continually failing to make > >>even small and useful progress in this area. > >>> > >>>Sylvain's approach of leaving the ERT in place so it can be used for > >>the use cases it was designed for while holding back on doing some of > >>the more complex things than might need either further work in the ERT, > >>or some more fundamental work in the RT (which feels like as L or M > >>timescales based on current progress) seemed pretty pragmatic to me. > >> > >>++, I really don't like the idea of rushing the revert of a feature that > >>went through significant design discussion especially when the author is > >>away and cannot defend it. > > > >Fair enough - I will WIP the revert until Phil is back. It's the right > >thing to do seeing that he is away. > > Well, it's as much (or more?) Paul Murray and Andrea Rosa :) > > >However - I don't agree with using the length of discussion around the > >feature as a valid argument against reverting. > > Neither do I. > > >I've supplied several technical arguments on the original thread to why > >I think we should revert it, and would expect a discussion that either > >refutes them, or provides alternative ways forward. > > > >Saying 'but we talked about it at length' is the ultimate appeal to > >imaginary authority and frankly not helping at all. > > Agreed. Perhaps it's just my provocative nature, but I hear a lot of "we've > already decided/discussed this" talk especially around the scheduler and RT > stuff, and I don't think the argument holds much water. We should all be > willing to reconsider design decisions and discussions when appropriate, and > in the case of the RT, this discussion is timely and appropriate due to the > push to split the scheduler out of Nova (prematurely IMO).
Yes, this is absolutely right. Even if we have approved a spec / blueprint we *always* reserve the right to change our minds at a later date if new information or points of view come to light. Hopefully this will be fairly infrequent and we won't do it lightly, but it is a key thing we accept as a possible outcome of the process we follow. 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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev