[Openstack] Nova DB Connection Pooling

Joshua Harlow harlowja at yahoo-inc.com
Tue Sep 27 17:44:09 UTC 2011


I was more of just commenting on the line in the multi-cluster doc that says:

"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?

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. :-)
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? Or you would have to switch the dashboard between different zones (this might make more sense but still seems sort of clunky). Similarly this seems to be the same with volume management where now u have X volume entry-points. Not that this is bad, it just seems like it starts to get very complicated :-)

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?) :-)

I just wouldn't want to manage this:
200 Huddle Zones/DC == 200 DB's per datacenter. :-(

On 9/27/11 12:21 AM, "Chris Behrens" <chris.behrens at RACKSPACE.COM> wrote:



Not sure the 'data that are shared' is the right wording below, but I think I get the point.  The one thing that jumps out to me as a current 'issue' is the fact that the instance_types table must be kept in sync.  I can't think of anything else at the moment, but there might be something.

And the comment (not quoted below) about 'X' dashboards *I think* is invalid.  I don't know much about it..  does it talk more than to API?  If not, just point it at top level zone.

I'm really not a fan of distributed DB architectures if they can be avoided.  They add a lot of unneeded complexity and a lot more potential for breakage.  The instance type issue can be solved differently.  That said, it can be an interesting discussion topic. :)

- Chris

On Sep 26, 2011, at 8:53 PM, Ed Leafe wrote:

> On Sep 26, 2011, at 10:14 PM, Joshua Harlow wrote:
>
>> It seems like it would be good to talk about this during the conference, since it seems sort of odd to have pieces of data that are shared across zones along with pieces of data that are not shared across zones.
>
>       What pieces of data are shared across zones?
>
>
> -- 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, please delete it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110927/d273db09/attachment.html>


More information about the Openstack mailing list