Open Stack

Makes sense. I'm sure there are use-cases for both scenarios. 

Shouldn't be a big deal to make a derived ZoneManager that persists the data. The overall mechanism would stay the same. This does, however, put us back in the position of deciding which capabilities become permanent additions to the Services table and which are customer-specific (since we don't want that table growing to accommodate every possible user).

And, since there's likely more than one Scheduler running, you'd need to make sure you're doing the right thing updating the database (not treading on another services updates) ... perhaps some sort of atomic time check/update?

-S

________________________________________
From: Dong-In David Kang [dkang at isi.edu]
Sent: Monday, June 06, 2011 11:45 AM
To: Sandy Walsh
Cc: Mark Washenberger; openstack at lists.launchpad.net; Jay Pipes; Ed Leafe
Subject: Re: [Openstack] distributed and heterogeneous schedulers

 I'm not sure if this discussion is still going on.
I want to advocate using persistent storage.

 We can consider power-down or power-up of some compute nodes to save power at the low usage of cloud.
(As far as I know) It is not supported by OpenStack now, but I believe it will be.
Let's assume that it is done by zone-manager.
If zone manager keeps capabilities of the compute nodes not in a persistent storage,
and zone manager dies and restarts, it will lose the information (capabilities) of the power-downed nodes.
And the power-downed nodes cannot send its capabilities to the zone manager because it is down.
One way to resolve this problem is that zone manager power-up those power-downed node to get their capabilities.
But, using persistent storage to store capabilities of computes nodes seems to be better solution.

 We USC/ISI are working on heterogeneous architecture support.
The issue of using persistent storage is related to our work.
Currently a compute node sends the information of heterogeneous architecture (such as accelerator type, number of accelerators, etc.) as a part of its capability to zone manager.
Zone manager treats it as a ephemeral data. So, the information of heterogeneous architecture is not stored to a persistent storage.
So, if a zone manager dies and restarts and a compute node with extra information of heterogeneous architecture was powered-down, the zone manager may never be aware of the capability of the power-downed node.

 Thanks,

 Dong-In

----------------------
Dr. Dong-In David Kang
Computer Scientist
USC/ISI

----- Original Message -----
From: "Sandy Walsh" <sandy.walsh at rackspace.com>
To: "Jay Pipes" <jaypipes at gmail.com>, "Ed Leafe" <ed.leafe at rackspace.com>
Cc: "Mark Washenberger" <mark.washenberger at rackspace.com>, openstack at lists.launchpad.net
Sent: Friday, April 15, 2011 2:24:21 PM
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