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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
