Open Stack

> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: 20 August 2014 14:13
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova] Scheduler split wrt Extensible Resource
> Tracking
> 
> 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.
> 
My point was more that reverting a patch that does meet the use cases it was designed to cover, even if there is something more fundamental that needs to be looked at to cover some new use cases that weren't considered at the time is the route to stagnation.   

It seems (unless I'm reading it wrong) that there is consensus that the RT is the issue here, not the way that ERT makes that current functionality more useable.

So sure, let's talk  (again) about how the RT can be re-designed, and follow Sylvain's suggestion to make sure that nothing hacky lands to work around those issues.  I just don't see why we have to block the small bits of progress that can be made in the meantime.   We seem to have been stuck in a loop staring at the scheduler for a long time now.