Open Stack

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