Open Stack

Hi Ed,

So it sounds like we're all talking about the same thing, we just need
to start a Nova glossary so we're all on the smae page of what terms
mean. :)  So it sounds like from my last email, kernel == scheduler,
and scheduler == best match.

I'm not too concerned about naming of things as long as they are
accurate. I thought "scheduler" was being a bit overloaded, as it
was originally only supposed to be the "best match" functionality you
describe. I think it would be fine to use kernel though, as the same
terms are used in many different contexts in computing, and this is
certainly a different context. Having said that, it doesn't really
matter as long as it works and folks can understand what it's doing
with a brief look. :)

As for the best way to locate the host when routing requests for
existing instances, the most straightforward way is to keep a lookup
table (probably another SQLite table would be easiest). This table
can stay up to date by registering callbacks with child zones, and
the child needs to have an API call for the parent zone to be able to
say "give me all changes after time X" for the initial sync (time=0)
or after a long outage (time=last update before going down).

-Eric

On Fri, Feb 25, 2011 at 08:27:24AM -0600, Ed Leafe wrote:
> 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