On 08/27/2013 09:26 AM, Daniel Salinas wrote:
Forwarding to ML. Sorry somehow this got sent directly to Auston.
Hi Daniel,
On perusing the API, my initial comment was that I would hope we can
remove the redundant key in the JSON serialized object returned by the
various calls?
For example, GET /instances/<ID> returns:
{
"instance": {
"created": "2013-05-08T22:43:34",
"flavor": ...
}
}
Can we get rid of the redundant "instance" key and just return:
{
"created": "2013-05-08T22:43:34",
"flavor": ...
}
Same for "list" results, like GET /clustertypes:
{
"clusterTypes": [
{
"id": "7782954c-ebec-42f0-894b-d3601016a91e",
"links": ...
}
]
}
The result should be an array, not an object with a single key that is
an array:
[
{
"id": "7782954c-ebec-42f0-894b-d3601016a91e",
"links": ...
}
]
Lists do not have any other attributes other than length. We shouldn't
dirty our JSON returns with the filth of XML. ;)
Best,
-jay
---------- Forwarded message ----------
From: *Daniel Salinas* <imsplit...@gmail.com <mailto:imsplit...@gmail.com>>
Date: Fri, Aug 23, 2013 at 3:18 PM
Subject: Re: [Openstack] [trove] - Discussion on Clustering and
Replication API
To: "McReynolds, Auston" <amcreyno...@ebay.com
<mailto:amcreyno...@ebay.com>>
Auston,
The wiki page you're looking through was one approach we discussed but
ultimately decided against. The current proposal is here:
https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API-Using-Instances
It is a bit of a misnomer to call it "using instances" since it uses
both /instance and /cluster but the consensus during design discussions
was that we were going to have a clustering api which provides a control
structure for clustering/replication, not instances. For example,
adding an instance to a cluster would be a PUT on /cluster/{id}, not
/cluster/{id}/nodes.
Also we discussed removing actions altogether so we won't have a promote
action but rather an explicit path for promotion for an instance of a
cluster. This path *should* be /cluster/{id}/promote with a body
containing the instance id being promoted.
If you get a chance to read through the above link and still have
questions feel free to let me know.
I will try to spend some time looking through your discussion points and
get back to you asap.
On Wed, Aug 21, 2013 at 7:46 PM, McReynolds, Auston
<amcreyno...@ebay.com <mailto:amcreyno...@ebay.com>> wrote:
Blueprint:
https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API
Questions:
* Today, /instance/{instance_id}/action is the single endpoint for all
actions on an instance (where the action is parsed from the payload).
I see in the newly proposed /clusters api that there's
/clusters/{cluster_id}/restart, etc. Is this a purposeful move from
"field of a resource" to sub-resources? If so, is there a plan to
retrofit the /instance api?
* For "Promote a Slave Node to Master", where is the request
indicating the promote action (explicitly or implicitly)? I don't see
it in the uri or the payload.
* "Create Replication Set" is a POST to /clusters, but "Add Node" is a
PUT to /clusters/{cluster_id}/nodes. This seems inconsistent given
both are essentially doing the same thing: adding nodes to a cluster.
What's the reasoning behind the divergence?
* What is the expected result of a resize action request on
/instance/{instance_id} for an instance that's a part of a cluster
(meaning the request could have alternatively been executed against
/cluster/{cluster_id}/nodes/{node_id})? Will it return an error?
Redirect the request to the /clusters internals?
Discussion:
Although it's common and often advised that the same flavor be used
for every node in a cluster, there are many situations in which you'd
purposefully buck the tradition. One example would be choosing a
beefier flavor for a slave to support ad-hoc queries from a tertiary
web application (analytics, monitoring, etc.).
Therefore,
{
"cluster":{
"nodes":3,
"flavorRef":"https://service/v1.0/1234/flavors/1";,
"name":"replication_set_1",
"volume":{
"size":2
},
"clusterConfig":{
"type":"https://service/v1.0/1234/clustertypes/1234";
}
}
}
is not quite expressive enough. One "out" is that you could force the
user to resize the slave(s) after the cluster has been completely
provisioned, but that seems a bit egregious.
Something like the following seems to fit the bill:
{
"cluster":{
"clusterConfig":{
"type":"https://service/v1.0/1234/clustertypes/1234";
},
"nodes":[
{
"flavorRef":"https://service/v1.0/1234/flavors/1";,
"volume":{
"size":2
}
},
{
"flavorRef":"https://service/v1.0/1234/flavors/3";,
"volume":{
"size":2
}
}]
}
}
but, which node is arbitrarily elected the master if the clusterConfig
is set to MySQL Master/Slave? When region awareness is supported in
Trove, how would you pin a specifically configured node to its
earmarked region/datacenter? What will the names of the nodes of the
cluster be?
{
"cluster":{
"clusterConfig":{
"type":"https://service/v1.0/1234/clustertypes/1234";
},
"nodes":[
{
"name":"usecase-master",
"flavorRef":"https://service/v1.0/1234/flavors/1";,
"volume":{
"size":2
},
"region": "us-west",
"nodeConfig": {
"type": "master"
}
},
{
"name":"usecase-slave-us-east"
"flavorRef":"https://service/v1.0/1234/flavors/3";,
"volume":{
"size":2
},
"region": "us-east",
"nodeConfig": {
"type": "slave"
}
},
{
"name":"usecase-slave-eu-de"
"flavorRef":"https://service/v1.0/1234/flavors/3";,
"volume":{
"size":2
},
"region": "eu-de",
"nodeConfig": {
"type": "slave"
}
}]
}
}
This works decently enough, but it assumes a simple master/slave
architecture. What about MySQL multi-master with replication?
See /doc/refman/5.5/en/mysql-cluster-replication-multi-master.html.
Now, a 'slaveof' or 'primary'/'parent' field is necessary to be more
specific (either that, or nesting of JSON to indicate relationships).
From above, it's clear that a "nodeConfig" of sorts is needed to
indicate whether the node is a slave or master, and to whom. Thus far,
a RDBMS has been assumed, but consider other offerings in the space:
How will you designate if the node is a seed in the case of Cassandra?
The endpoint snitch for a Cassandra node? The cluster name for
Cassandra or the replica-set for Mongo? Whether a slave should be
daisy-chained to another slave or attached to directly to master in
the case of Redis?
Preventing service type specifics from bleeding into what should be a
generic (as possible) schema is paramount. Unfortunately, "nodeConfig"
as you can see starts to become an amalgamation of fields that are
only applicable in certain situations, making documentation, codegen
for clients, and ease of use, a bit challenging. Fast-forward to when
editable parameter groups become a priority (a.k.a. being able to set
name-value-pairs in the service type's CONF). If users/customers
demand the ability to set things like buffer-pool-size while
provisioning, these fields would likely be placed in "nodeConfig",
making the situation worse.
Here's an attempt with a slightly different approach:
https://gist.github.com/amcr/96c59a333b72ec973c3a
From there, you could build a convenience /cluster api to facilitate
multi-node deployments (vs. building and associating node by node), or
wait for Heat integration.
Both approaches have their strengths, so I'm convinced it's the
blending of the two that will result in what we're all looking for.
Thoughts?
Cheers,
amc
_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
<mailto:openstack@lists.openstack.org>
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
