openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

Thanks for the info :-)

Is there any info on what it does aggregate and what it doesn't. Like flavors aren't aggregated (I would think)? But instance listing is aggregated.

On 9/27/11 1:54 PM, "Ed Leafe" <ed.leafe@xxxxxxxxxxxxx> wrote:

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.