On Fri, Apr 15, 2011 at 11:19 AM, Ed Leafe <[email protected]> wrote: > 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.
Yes, I'm aware of how the Zone Manager works. But, 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. > 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. 2 out of the 3 of your examples are flags. Look, really, the point I was getting at in my original response was that when we store in a database information about an entity, we should store common attributes in the main table and uncommon/infrequently accessed attributes in the corresponding "_properties" (or "_metadata") table. -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
