Do you have any specific examples on that? I'm not opposed to adding more to the replication contract but I want to be sure that it is important to the end user of the api. I can see some edge cases for saying "replication_type": "async-master-slave" or something like that. This becomes more important for datastore technologies that support multiple replication types/methodologies. Imagine a world where trove supports using mysql async replication as well as something like tungsten replicator.
On Wed, Oct 23, 2013 at 10:06 AM, Daniel Morris <daniel.mor...@rackspace.com > wrote: > Would it be beneficial in this case to extend the meta-data model of the > replication contract to allow for additional key/value pairs in the > meta-data to account for DB specific and/or replication and clustering > specific meta-data? > > -Daniel > > From: Daniel Salinas <imsplit...@gmail.com> > Reply-To: OpenStack Development Mailing List > <openstack-dev@lists.openstack.org> > Date: Wednesday, October 23, 2013 9:42 AM > To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org > > > Subject: Re: [openstack-dev] [Trove] Replication and Clustering API > > > >Galera cluster, in this model would be considered a service type or > >datastore type not a replication type. All clusters would be treated > >this way. The method of replication is really not important to the api > >IMO but rather the contract should > > reflect what host has copies of data (in whole or in part) on other > >hosts. How the data gets to each host is a function of the underlying > >technology. That is not to say that we couldn't add more verbose > >information to the replication contract but I haven't > > yet seen where or how that's important to the end user. > > > > > > > >On Tue, Oct 22, 2013 at 5:32 PM, Georgy Okrokvertskhov > ><gokrokvertsk...@mirantis.com> wrote: > > > >Hi, > > > >I don't see the replication type in the metadata replication contract. > >For example someone can use MySQL Galera cluster with synchronous > >replication + asynchronous replication master-slave for backup to remote > >site. > > > >MS SQL offers alwaysON availability groups clustering with pair of > >synchronous replication plus up to 3 nodes with asynchronous replication. > >Also there are some existing different mechanisms like data mirroring > >(synchronous or asynchronous) or log shipping. > > > >So my point is that when you say replication, it is not obvious which > >type of replication is used. > > > >Thanks > >Georgy > > > > > > > > > > > >On Tue, Oct 22, 2013 at 12:37 PM, Daniel Salinas > ><imsplit...@gmail.com> wrote: > > > > > > > >We have drawn up a new spec for the clustering api which removes the > >concept of a /clusters path as well as the need for the /clustertypes > >path. The spec lives here now: > > > >https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API > > > > > >Initially I'd like to get eyes on this and see if we can't generate some > >discussion. This proposal is far reaching and will ultimately require a > >major versioning of the trove API to support. It is an amalgam of ideas > >from Vipul, hub_cap and a few others but > > we feel like this gets us much closer to having a more intuitive > >interface for users. Please peruse the document and lets start working > >through any issues. > > > >I would like to discuss the API proposal tomorrow during our weekly > >meeting but I would welcome comments/concerns on the mailing list as well. > > > > > > > > > > > >_______________________________________________ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > > > >-- > >Georgy Okrokvertskhov > >Technical Program Manager, > >Cloud and Infrastructure Services, > >Mirantis > >http://www.mirantis.com <http://www.mirantis.com/> > >Tel. +1 650 963 9828 <tel:%2B1%20650%20963%209828> > >Mob. +1 650 996 3284 <tel:%2B1%20650%20996%203284> > > > > > >_______________________________________________ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev