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: firstname.lastname@example.org > <mailto:email@example.com> >> > 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. 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. >> >> 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. However - I don't agree with using the length of discussion around the feature as a valid argument against reverting. 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. N. >> >> Phil >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStackfirstname.lastname@example.org > <mailto:OpenStackemail@example.com> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev