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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
