On 07/14/2014 12:10 PM, Jay Pipes wrote:
On 07/14/2014 10:16 AM, Sylvain Bauza wrote:
From an operator perspective, people waited so long for having a
scheduler doing "scheduling" and not only "resource placement".
Could you elaborate a bit here? What operators are begging for the
scheduler to do more than resource placement? And if they are begging
for this, what use cases are they trying to address?
I'm curious about this as well, what more than resource placement
*should* the scheduler handle?
On the other hand, I *do* see a usecase for a more holistic scheduler
that can take into account a whole group of resources at once (multiple
instances, volumes, networks, etc. with various constraints on them,
combined with things like server groups and host aggregates).
In a simple scenario, suppose a compute node fails. I want to evacuate
all the instances that had been on that compute node, but ideally I'd
like the scheduler to look at all the instances simultaneously to try to
place them...if it does them one at a time it might make a decision that
doesn't use resources in an optimal way, possibly even resulting in the
failure of one or more evacuations even though there is technically
sufficient room in the cluster for all instances.
Alternately, suppose I have a group of instances that really want to be
placed on the same physical network segment. (For low latency, maybe.)
Lastly, I think that any information that fed into the original
scheduler decision should be preserved for use by subsequent scheduling
operations (migration, evacuation, etc.) This includes stuff like
image/flavor metadata, boot-time scheduler hints, etc.
Chris
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
