Open Stack

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.

-Sylvain