Hi y'all, getting any sleep before Feature Freeze? As you know, one of the main design tenants of OpenStack is Share Nothing (where possible). http://wiki.openstack.org/BasicDesignTenets
That's the mantra we've been chanting with Zones. But it does cause a problem with a particular Use Case: "Show me all Customer X Instances, across all Zones." This is an expensive request. We have to poll all zones and ask them to return a list of matching instances. There has been some water cooler chat about some things we could do to make this more efficient in the near term. One proposal has been to assume a single database, replicated across zones. I'll call it SDB for short. With SDB we can have a join table that links Zone to Instance ... keeping a record of all instances across zones. Maybe it's a completely separate set of tables? Maybe it's a separate replicated db? The intention is to let us talk to the appropriate zone directly. Sure, there are a ton more optimizations we could make if we go further with SDB. We could store all the Zone capabilities in the db to make Zone selection faster. We could store all the customers in the db to make multi-tenant easier. But that's not what we're talking about here. We're talking about the bare minimum required to make the get_instances query fast. Conversely, there are issues with a single DB. The largest being the implication it has on Bursting (Hybrid Private/Public clouds) ... a pretty funky feature imho. Personally, I think the same query gains can be obtained by creating a separate db using off-the-shelf ETL tools to create cache/read-only db's. http://en.wikipedia.org/wiki/Extract,_transform,_load I was considering SDB for Zones (phase 4), but for now, I'm going to stick with the original plan of separate databases (1 per zone) and see what the performance implications are. What are your thoughts on this issue? ... let the games begin! -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : firstname.lastname@example.org Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp