Open Stack

The solver-scheduler is designed to solve for an arbitrary list of instances of different flavors. We need to have some updated apis in the scheduler to be able to pass on such requests. Instance group api is an initial effort to specify such groups.



Even now the existing solver scheduler patch,  works for a group request,  only that it is a group of a single flavor. It still solves once for the entire group based on the constraints on available capacity.



With updates to the api that call the solver scheduler we can easily demonstrate how an arbitrary group of VM request can be satisfied and solved together in a single constraint solver run. (LP based solver for now in the current patch, But can be any constraint solver)



Thanks,

Yathi.





------ Original message------

From: Chris Friesen

Date: Mon, 2/3/2014 11:24 AM

To: openstack-dev at lists.openstack.org;

Subject:Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler



On 02/03/2014 12:28 PM, Khanh-Toan Tran wrote:

> Another though would be the need for Instance Group API [1].
> Currently users can only request multiple instances of the same
> flavors. These requests do not need LP to solve, just placing
> instances one by one is sufficient. Therefore we need this API so
> that users can request instances of different flavors, with some
> relations (constraints) among them. The advantage is that this logic
> and API will help us add Cinder volumes with ease (not sure how the
> Cinder-stackers think about it, though).

I don't think that the instance group API actually helps here.  (I think
it's a good idea, just not directly related to this.)

I think what we really want is the ability to specify an arbitrary list
of instances (or other things) that you want to schedule, each of which
may have different image/flavor, each of which may be part of an
instance group, a specific network, have metadata which associates with
a host aggregate, desire specific PCI passthrough devices, etc.

An immediate user of something like this would be heat, since it would
let them pass the whole stack to the scheduler in one API call.  The
scheduler could then take a more holistic view, possibly doing a better
fitting job than if the instances are scheduled one-at-a-time.

Chris

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140203/6f85f613/attachment.html>