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