← Back to team overview

nova team mailing list archive

Re: Data architecture

 

Nothing is shared between the schedulers, and updates are eventually
consistent. Schedulers would subscribe to events for hosts, and
the hosts would notify the schedulers on changes. For example,
it may simply be on creation and deletion so it just knows what
clusters/guests/hosts exist and how to route requests to them. We'll
most likely want to store this all in memory, but we can put a simple
API in front of it so we could switch in the future. Redis may even
be a good choice since it already drops snapshots.

-Eric

On Wed, Aug 04, 2010 at 03:19:22PM -0400, Michael Gundlach wrote:
>    On Wed, Aug 4, 2010 at 2:57 PM, Paul Voccio <paul.voccio@xxxxxxxxxxxxx>
>    wrote:
> 
>      Shouldn*t the layer be pluggable if I wanted a different datastore?
> 
>    FYI in case you missed the thread on WSGI, modules, and services: whether
>    the memory were local or in a memcache or otherwise, the layer would be
>    pluggable.  We'll provide a caching library that is a language binding to
>    pluggable cache backends -- mock, local, memcache, or otherwise.  Auth*
>    will have the same structure, allowing mock, LDAP, etc.
>    So while I don't think the cache should be in-memory as Eric has drawn it,
>    I think pluggability is still assumed in the diagram.
>    Michael



Follow ups

References