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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
