Open Stack

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.morris at 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 <imsplitbit at gmail.com>
> Reply-To:  OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Date:  Wednesday, October 23, 2013 9:42 AM
> To:  OpenStack Development Mailing List <openstack-dev at 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
> ><gokrokvertskhov at 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
> ><imsplitbit at 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 at 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 at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131023/55d8b77f/attachment.html>