Open Stack

Jagane, good question.

There can be many schedulers running within a Zone (each with their own ZoneManager). They service scheduler requests round-robin thanks the AMQP. We can have them not listen for events until, let's say, 30 seconds has elapsed (the update interval).

Thanks for the note about hadoop ... didn't know that!

-S


________________________________________
From: Jagane Sundar [jagane at sundar.org]
Sent: Friday, April 15, 2011 3:39 PM
To: Sandy Walsh; Jay Pipes; Ed Leafe
Cc: Mark Washenberger; openstack at lists.launchpad.net
Subject: RE: [Openstack] distributed and heterogeneous schedulers

What happens if a ZoneManager process dies? When the ZoneManager restarts, the compute nodes will send their attributes to the newly restarted ZoneManager and the in-memory list of attributes will be reconstructed, right?
The only downside to this approach is the (probably short) time that it takes for the restarted ZoneManager to reconstruct its in-memory db of host attributes.

As an unrelated side note, the folks over in Hadoop land use this sort of 'in-memory data-structures fed by heartbeats' approach with much success.

- Jagane
________________________________________
From: openstack-bounces+jagane=sundar.org at lists.launchpad.net [openstack-bounces+jagane=sundar.org at lists.launchpad.net] On Behalf Of Sandy Walsh [sandy.walsh at rackspace.com]
Sent: Friday, April 15, 2011 2:24 PM
To: Jay Pipes; Ed Leafe
Cc: Mark Washenberger; openstack at lists.launchpad.net
Subject: Re: [Openstack] distributed and heterogeneous schedulers

Each update from the services are atomic updates ... fully self contained.

Why does this need to be in a persistent store?

-S
________________________________________
From: Jay Pipes [jaypipes at gmail.com]
>  you still need a persistent data store for attributes of the host. Just because you
> store a cached in-memory copy of instance attributes, doesn't mean you
> don't need a persistent data store. You still need a persistent data
> store regardless of whether it's a database table, a FLAG value, or
> /proc/cpuinfo.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp