[openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"
Cheng, Yingxin
yingxin.cheng at intel.com
Wed Feb 17 16:03:23 UTC 2016
On Wed, 17 February 2016, Sylvain Bauza wrote
(sorry, quoting off-context, but I feel it's a side point, not the main discussion)
Le 17/02/2016 16:40, Cheng, Yingxin a écrit :
IMHO, the authority to allocate resources is not limited by compute nodes, but also include network service, storage service or all other services which have the authority to manage their own resources. Those "shared" resources are coming from external services(i.e. system) which are not compute service. They all have responsibilities to push their own resource updates to schedulers, make resource reservation and consumption. The resource provider series provides a flexible representation of all kinds of resources, so that scheduler can handle them without having the specific knowledge of all the resources.
No, IMHO, the authority has to stay the entity which physically create the instance and own its lifecycle. What the user wants when booting is an instance, not something else. He can express some SLA by providing more context (implicit thru aggregates or flavors) or explicit (thru hints or AZs) that could be not compute-related (say a network segment locality or a volume-related thing) but at the end, it will create an instance on a compute node that matches the requirements.
Cinder and Neutron shouldn't manage which instances are on which hosts, they just have to provide the resource types and possible allocations (like a taken port)
-Sylvain
Yes, thought twice. The cinder project also has its own scheduler, so it is not the responsibility of nova-scheduler to schedule all pieces of resources. Nova-scheduler is responsible to boot instances, it has a limited scope to compute services.
-Yingxin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160217/aa5757c5/attachment.html>
More information about the OpenStack-dev
mailing list