Open Stack

Le 11/07/2014 13:14, John Garbutt a écrit :
> 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.
>
> I was imagining the extensible resource tracker to become (sort of)
> equivalent to cinder volume drivers. Also the persistent resource
> claims will give us another plugin point for gantt. That might not be
> enough, but I think it easier to see once the other elements have
> moved.
>
> But the key point thing I like, is how the current approach amounts to
> refactoring, similar to the cinder move. I feel we should stick to
> that if possible.
>
> John

Thanks John for your feedback. I'm +1 with you, we need to go on the way
we defined with all the community, create Gantt once the prereqs are
done (see my above and first mail for these) and see after if the line
is needed to move.

I think this discussion should also be interesting if we also take in
account the current Cinder and Neutron scheduling needs, so we would say
if it's the good direction.


Others ?

Note: The spec https://review.openstack.org/89893 is not yet approved
today, as the Spec approval freeze happened, I would like to discuss
with the team if we can have an exception on it so the work could happen
by Juno.


Thanks,
-Sylvain