Open Stack

On Feb 24, 2011, at 2:02 PM, Eric Day wrote:

> I agree with Vish, I think the correct approach is 3. I have some
> ideas on terminology and how to think about this. A "scheduler"
> should not be it's own top-level service. It should instead be a
> plugin point (more like auth or db). It would plug into new service
> called "kernel". Another way to look at it is s/scheduler/kernel/
> and expand kernel.


	As I've been reading this thread, it did strike me that the terminology was being used differently by various people. Let me see if I can explain the way we've been using the terms in the development currently underway among the Ozone team.

	Given an Openstack deployment with several nested zones, most external API requests to interact with a VM will need to be routed to the appropriate compute node. The top-level API will know nothing about the VM, and so some sort of communication must be established to handle resolving these calls. This is what we have been calling the "scheduler", and what you seem to be referring to as the "kernel". Example: a request to pause a VM will have to be routed through the zone structure to find the host for that VM in order to pause it. The method used to efficiently locate the host is currently the focus of much discussion.

	One other such task (and probably the most involved) will be the creation of a new VM. This will require determining which hosts can accommodate the proposed instance, and a way of weighting or otherwise choosing the host from among all that are available. It will also require additional actions, such as establishing the network configuration, but let's keep this discussion focused. The process of selecting the host to receive the new VM is something we don't have a catchy name for, but we have been referring to "best match", since that's the current term used in the Slicehost codebase. We have assumed that this will be pluggable, with the default being the current random selector, so that the way Rackspace allocates its VMs can be customized to their needs, while still allowing everyone else to create their own selection criteria.

	I hope that this clarifies some of what we have been talking about. BTW, I understand your choice of the term "kernel", but I would prefer something that might be less confusing, since kernel already has a common meaning in computing.


-- Ed Leafe