Open Stack

On 07/14/2014 10:16 AM, Sylvain Bauza wrote:
> Le 12/07/2014 06:07, Jay Pipes a écrit :
>> On 07/11/2014 07:14 AM, John Garbutt wrote:
>>> On 10 July 2014 16:59, Sylvain Bauza <sbauza at redhat.com> wrote:
>>>> Le 10/07/2014 15:47, Russell Bryant a écrit :
>>>>> On 07/10/2014 05:06 AM, Sylvain Bauza wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> === tl;dr: Now that we agree on waiting for the split
>>>>>> prereqs to be done, we debate on if ResourceTracker should
>>>>>> be part of the scheduler code and consequently Scheduler
>>>>>> should expose ResourceTracker APIs so that Nova wouldn't
>>>>>> own compute nodes resources. I'm proposing to first come
>>>>>> with RT as Nova resource in Juno and move ResourceTracker
>>>>>> in Scheduler for K, so we at least merge some patches by
>>>>>> Juno. ===
>>>>>>
>>>>>> Some debates occured recently about the scheduler split, so
>>>>>> I think it's important to loop back with you all to see
>>>>>> where we are and what are the discussions. Again, feel free
>>>>>> to express your opinions, they are welcome.
>>>>> Where did this resource tracker discussion come up?  Do you
>>>>> have any references that I can read to catch up on it?  I
>>>>> would like to see more detail on the proposal for what should
>>>>> stay in Nova vs. be moved.  What is the interface between
>>>>> Nova and the scheduler here?
>>>>
>>>> Oh, missed the most important question you asked. So, about
>>>> the interface in between scheduler and Nova, the original
>>>> agreed proposal is in the spec
>>>> https://review.openstack.org/82133 (approved) where the
>>>> Scheduler exposes : - select_destinations() : for querying the
>>>> scheduler to provide candidates - update_resource_stats() : for
>>>> updating the scheduler internal state (ie. HostState)
>>>>
>>>> Here, update_resource_stats() is called by the
>>>> ResourceTracker, see the implementations (in review)
>>>> https://review.openstack.org/82778 and
>>>> https://review.openstack.org/104556.
>>>>
>>>> The alternative that has just been raised this week is to
>>>> provide a new interface where ComputeNode claims for resources
>>>> and frees these resources, so that all the resources are fully
>>>> owned by the Scheduler. An initial PoC has been raised here
>>>> https://review.openstack.org/103598 but I tried to see what
>>>> would be a ResourceTracker proxified by a Scheduler client here
>>>> : https://review.openstack.org/105747. As the spec hasn't been
>>>> written, the names of the interfaces are not properly defined
>>>> but I made a proposal as : - select_destinations() : same as
>>>> above - usage_claim() : claim a resource amount -
>>>> usage_update() : update a resource amount - usage_drop(): frees
>>>> the resource amount
>>>>
>>>> Again, this is a dummy proposal, a spec has to written if we
>>>> consider moving the RT.
>>>
>>> While I am not against moving the resource tracker, I feel we
>>> could move this to Gantt after the core scheduling has been
>>> moved.
>>
>> Big -1 from me on this, John.
>>
>> Frankly, I see no urgency whatsoever -- and actually very little
>> benefit -- to moving the scheduler out of Nova. The Gantt project I
>> think is getting ahead of itself by focusing on a split instead of
>> focusing on cleaning up the interfaces between nova-conductor,
>> nova-scheduler, and nova-compute.
>>
>
> -1 on saying there is no urgency. Don't you see the NFV group saying
> each meeting what is the status of the scheduler split ?

Frankly, I don't think a lot of the NFV use cases are well-defined.

Even more frankly, I don't see any benefit to a split-out scheduler to a 
single NFV use case.

> Don't you see each Summit the lots of talks (and people attending
> them) talking about how OpenStack should look at Pets vs. Cattle and
> saying that the scheduler should be out of Nova ?

There's been no concrete benefits discussed to having the scheduler 
outside of Nova.

I don't really care how many people say that the scheduler should be out 
of Nova unless those same people come to the table with concrete reasons 
why. Just saying something is a benefit does not make it a benefit, and 
I think I've outlined some of the very real dangers -- in terms of code 
and payload complexity -- of breaking the scheduler out of Nova until 
the interfaces are cleaned up and the scheduler actually owns the 
resources upon which it exercises placement decisions.

> From an operator perspective, people waited so long for having a
> scheduler doing "scheduling" and not only "resource placement".

Could you elaborate a bit here? What operators are begging for the 
scheduler to do more than resource placement? And if they are begging 
for this, what use cases are they trying to address?

I'm genuinely curious, so looking forward to your reply here! :)

snip...

>> As for the idea that things will get *easier* once scheduler code
>> is broken out of Nova, I go back to my original statement that I
>> don't really see the benefit of the split at this point, and I
>> would just bring up the fact that Neutron/nova-network is a shining
>> example of how things can easily backfire when splitting of code is
>> done too early before interfaces are cleaned up and
>> responsibilities between internal components are not clearly agreed
>> upon.
>
> Please, please, don't mix the rationale for extensible Resource
> Tracker and the current efforts for moving out the Scheduler. Both of
> them try to have an agnostic and heterogeneous scheduler, but both
> efforts are independent.
>
> The ResourceTracker is something pure Nova. Saying to Gantt "I want
> to store this data" and "I want you to select a destination" is
> something enough agnostic for not including the port of
> ResourceTracker to the Scheduler.

Sorry, I'm not following you. Who is saying to Gantt "I want to store 
this data"?

All I am saying is that the thing that places a resource on some 
provider of that resource should be the thing that owns the process of a 
requester *claiming* the resources on that provider, and in order to 
properly track resources in a race-free way in such a system, then the 
system needs to contain the resource tracker.

> While I approve to define the interfaces now, there is no reason tho
> to say we would have to change anything in how Nova is doing that.
> The role of Gantt is to define the interfaces, make the line
> Scheduler vs. Nova and forklift the Scheduler into a single project.
> No big bang is needed here.

Yeah, I just don't see the need to split the scheduler at this point, 
sorry. :(

Best,
-jay