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 [[email protected]] Sent: Monday, June 06, 2011 11:45 AM To: Sandy Walsh Cc: Mark Washenberger; [email protected]; 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" <[email protected]> To: "Jay Pipes" <[email protected]>, "Ed Leafe" <[email protected]> Cc: "Mark Washenberger" <[email protected]>, [email protected] 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 [[email protected]] > 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 : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
