Open Stack

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