Open Stack

On Fri, Apr 15, 2011 at 11:19 AM, Ed Leafe <ed.leafe at rackspace.com> 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