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