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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
