Open Stack

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.day at hp.com
> >><mailto:philip.day at hp.com>> wrote:
> >>>
> >>>>-----Original Message-----
> >>>>From: Nikola Đipanov [mailto:ndipanov at redhat.com
> >><mailto:ndipanov at redhat.com>]
> >>>>Sent: 19 August 2014 17:50
> >>>>To: openstack-dev at lists.openstack.org
> >><mailto:openstack-dev at lists.openstack.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 :|