Open Stack

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