Open Stack

Le 20/08/2014 15:13, Daniel P. Berrange a écrit :
> 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.

While I totally understand the possibility to change our minds about an 
approved spec, I'm a bit worried about the timeline and how it can 
possibly impact deliveries.
In our case, the problem was raised in between 2 and 3 months after the 
design session occurred, and more importantly, 1 week before Feature 
Proposal Freeze.
As a consequence, it freezes the specification and we loose the 
possibility to split the Scheduler by Juno.

I know there are discussions about how Nova should handle feature 
delivery, I just want to make sure that this corner case is part of the 
talks. IMHO, we need to make sure at least all cores validate a spec 
(either explicitely or implicitely - by not giving -1 in less than 2 
weeks once the spec validated, for example) or this situation could 
occur more than infrequently.

My 2 cents,
-Sylvain



> Regards,
> Daniel