On Sep 27, 2011, at 12:44 PM, Joshua Harlow wrote:
> “Each deployment also gets its own Database. The Schema of each database is
> the same for all deployments at all levels. The difference between
> deployments is, depending on the services running within that Zone, not all
> the database tables may be used.” Is there a doc that shows what is used and
> what is not?
It's not a defined difference; it's a matter of usage. IOW, a zone
might not have any compute services running at all, but instead may serve as an
aggregator of child zones, and thus wouldn't "need" the tables that support
hosts. E.g., a datacenter zone might have several 'section' zones, each of
which corresponds to a different area in the DC. Each of those sections may be
divided into several zones that are each composed of several zones, each of
which actually has compute resources. In this example, the outer zones serve
only to provide horizontal scalability by aggregating their child zones. The
database tables that are involved in working with compute resources would be
empty, since they are not used at that level, but they would still need to be
present.
> As for each zone, the X dashboards I think would be required where X is each
> zone (since the zone “stuff” is really only in the scheduler). Correct me if
> I am wrong. :-)
You're wrong. :)
I think you're missing the way that compute resources roll up the zone
hierarchy. If you ask for all instances for a client at a particular zone, it
will return the instances present in its hosts, if any, and all of its child
zones' hosts, and their children, etc. That's what I mean by zones serving as
aggregators.
> Just from looking at that page, each zone has an API entry-point, and unless
> the “parent” zone does aggregation of child zone information then wouldn’t
> separate dashboards be needed?
See, you answered your own question. Parents do indeed aggregate child
zone information.
> I agree that distributed DB can be more complicated, but sometimes its worth
> it (if it makes X turn into 1 then it might be better?) :-)
We discussed the pros and cons of a distributed DB; personally, I was
in favor of Cassandra rather than a replicated MySQL, but I think that the
unfamiliarity of many in those early days with Cassandra ruled out that option.
We instead decided on a "shared nothing" approach to zones, where a parent knew
of its children, but the children were ignorant of their parents. It's sort of
a fractal design: you can drill down the nested zones, and at each level, they
function independently and identically.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
