Open Stack

On 07/20/2015 11:40 AM, Clint Byrum wrote:

> To your earlier point about state being abused in the system, I
> totally 100% agree. In the past I've wondered a lot if there can be a
> worker model, where compute hosts all try to grab work off queues if
> they have available resources. So API requests for boot/delete don't
> change any state, they just enqueue a message. Queues would be matched
> up to resources and the more filter choices, the more queues. Each
> time a compute node completed a task (create vm, destroy vm) it would
> re-evaluate all of the queues and subscribe to the ones it could satisfy
> right now. Quotas would simply be the first stop for the enqueued create
> messages, and a final stop for the enqueued delete messages (once its
> done, release quota). If you haven't noticed, this would agree with Robert
> Collins's suggestion that something like Kafka is a technology more suited
> to this (or my favorite old-often-forgotten solution to this , Gearman. ;)
>
> This would have no global dynamic state, and very little local dynamic
> state. API, conductor, and compute nodes simply need to know all of the
> choices users are offered, and there is no scheduler at runtime, just
> a predictive queue-list-manager that only gets updated when choices are
> added or removed. This would relieve a ton of the burden currently put
> on the database by scheduling since the only accesses would be simple
> read/writes (that includes 'server-list' type operations since that
> would read a single index key).

Some questions:

1) Could you elaborate a bit on how this would work?  I don't quite understand 
how you would handle a request for booting an instance with a certain set of 
resources--would you queue up a message for each resource?

2) How would it handle stuff like weight functions where you could have multiple 
compute nodes that *could* satisfy the requirement but some of them would be 
"better" than others by some arbitrary criteria.

3) The biggest improvement I'd like to see is in group scheduling.  Suppose I 
want to schedule multiple instances, each with their own resource requirements, 
but also with interdependency between them (these ones on the same node, these 
ones not on the same node, these ones with this provider network, etc.)  The 
scheduler could then look at the whole request all at once and optimize it 
rather than looking at each piece separately.  That could also allow relocating 
multiple instances that want to be co-located on the same compute node.

Chris