openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2011/5/23 Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>:
> To Soren's point about "losing the ability to rely on a fixed set of
> topics in the message queue for doing scheduling" this is not the case,
> there are no new topics introduced.

That's not exactly what I meant.

If we stuck with the simple flavours that we have right now, we could
schedule stuff exclusively using the message queue. The scheduler
would not need to know *anything* about the various compute nodes.
Scheduling an instance of flavour X would be achieved simply by
sending a "run this instance" message on the message queue with the
"flavour-X" topic. Any compute node able to accommodate an instance of
that size would be subscribed to that topic, and the message queue
would simply route the message to a "random" one of them. As a compute
node fills up, it'll unsubscribe from the topics representing flavours
that it no longer has room for. This sounds Very Scalable[tm] to me :)

Even if all the scheduling attributes we come up with were discrete
and enumerable, the cartesian product of all of them is potentially
*huge*, so having a topic for each of the possible combinations sounds
like very little fun. If any of them are not enumerable, it gets even
less fun. So, adding these capabilities would get in the way of
implementing something like the above. I guess it could be a
configuration option, i.e. if you choose the rich scheduling option
set, you don't get to use the cool scheduler.

--
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/