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 > Tel. +1 650 963 9828 > Mob. +1 650 996 3284 > > _______________________________________________ > 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
