Le 02/12/2013 18:12, Russell Bryant a écrit :
On 12/02/2013 10:59 AM, Gary Kotton wrote:
I think that this is certainly different. It is something that we we want
and need a user facing API.
Examples:
  - aggregates
  - per host scheduling
  - instance groups

Etc.

That is just taking the nova options into account and not the other
modules. How doul one configure that we would like to have storage
proximity for a VM? This is where things start to get very interesting and
enable the cross service scheduling (which is the goal of this no?).
An explicit part of this plan is that all of the things you're talking
about are *not* in scope until the forklift is complete and the new
thing is a functional replacement for the existing nova-scheduler.  We
want to get the project established and going so that it is a place
where this work can take place.  We do *not* want to slow down the work
of getting the project established by making these things a prerequisite.

While I can understand we need to secure the forklift, I also think it would be a good thing to step up defining what would be the scheduling-as-a-service in the next steps even if they are not planned yet.

There is already an RPC interface defining what *is* the scheduler, my concern is just to make sure this API (RPC or REST anyway) wouldn't it be too sticked to Nova instances so that planning to deliver for Cinder volumes or Nova hosts would be hard. In other terms, having the RPC methods enough generic to say "add this entity to this group" or "elect entities from this group" would be fine.

-Sylvain


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to