openstack team mailing list archive
Mailing list archive
Re: distributed and heterogeneous schedulers
This is getting totally off-track :)
My point was that if you are going to put data in a database table,
the attributes that go into the main table should be the attributes
that are common to all types of an entity, otherwise, use the table
that stores the custom key/value pairs.
On Fri, Apr 15, 2011 at 11:56 AM, Ed Leafe <ed.leafe@xxxxxxxxxxxxx> wrote:
> On Apr 15, 2011, at 11:43 AM, Jay Pipes wrote:
>> 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
> Not sure I follow why you need a persistent data store. If a host goes offline, its data is no longer being reported, and it is not considered in the selection process. What value does a database lookup provide?
>>>> 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.
> For a host, yes. For a zone, no.
> If a host is added to a zone with a different cpu or os type, the zone now has an additional capability. If that host later goes offline, the zone will no longer have that capability. At the zone level, these are dynamic.
> -- Ed Leafe