Open Stack

On Apr 15, 2011, at 10:37 AM, Jay Pipes wrote:

> The extra data would be more for the compute_nodes table I think, or
> is it called hosts now?


	I'm not sure how useful the compute_nodes table is anymore, at least not for scheduler. Currently only libvirt seems to populate it. I know it's not used at all with XenServer.

	With the addition of zones, what we're moving toward is having the services periodically report their status to their zone manager, and the ZM managing that information in an internal dict structure rather than read/writing to a table. The scheduler will use that info in the ZM to make choices when provisioning a new instance. One of the benefits of such an approach is that if different virt types need to report different capabilities, you don't need a big honking table with lots of unused columns, and adding a new bit of info doesn't require a migration script.

On Apr 15, 2011, at 10:58 AM, Jay Pipes wrote:

>> As mentioned before, each service reports their capabilities to the ZoneManager via a rabbit call. There is no need to update any tables since this is all ephemeral and are raw python data structures. ie. make them as rich as you like.
> 
> Well, that's a bit of a misnomer ;) The persistent capabilities of a
> zone are currently set in FLAG values, no? :)

	Capabilities include things such as available disk/memory, cpu type, os type, etc., and only a few of those would lend themselves to FLAGs. 



-- Ed Leafe