2011/5/23 Sandy Walsh <sandy.wa...@rackspace.com>: > 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/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp