Difference between revisions of "Cue/api1vsapi2"
(→API Approach 2 Pros/Cons) |
(→API Approach 1 Vs API Approach 2) |
||
Line 47: | Line 47: | ||
* Endpoint list mapping to specific node(s) not as clear. | * Endpoint list mapping to specific node(s) not as clear. | ||
|} | |} | ||
+ | |||
+ | == Extending to Custom Messaging Cluster Configurations == |
Revision as of 19:29, 15 December 2014
Contents
API Approach 1 Vs API Approach 2
This page will analyze the comparison between the two main API approaches for project Cue.
The first approach is located here: https://wiki.openstack.org/wiki/Cue/api
The second approach is located here: https://wiki.openstack.org/wiki/Cue/api_2
API Approach 1 Summary
The first approach to the API provides more visibility on the inner structures and configuration of the messaging clusters deployed by Cue. This exposure would allow the user additional control on a per-node configuration before and after cluster deployment. This lends to a more hands-on deployment and configuration structure allowing the user finer level control. On the other hand, this can lead to miss-configured and unstable clusters.
When the user creates a new cluster (POST), the API accepts the general cluster settings and a list of "nodes" which currently only contains VM flavor (e.g. small, medium, large). The reasoning to accept a node list of flavors even though it only makes sense to have all nodes in a cluster be the same flavor is with respect to consistency with the JSON response. The response body contains the same structure as the request body, where the nodes list now holds additional information about the nodes in the new cluster (e.g. node id, status, flavor..). The overall API is well positioned to expose full node by node control of Messaging clusters for the user. For a cluster update, the user can specify exactly which node to update, add or remove.
API Approach 2 Summary
The second approach to the API hides per-node details in a cluster. The API accepts configuration settings for a cluster as a whole, for example flavor and size which denote the overall node flavor and number of nodes respectively. This design minimizes internal per-node configuration and therefore lends to a messaging deployment system that will automate the full deployment process with minimal user intervention and therefore reducing possible user related errors.
An update to a cluster is issued by changing cluster-level parameters such as size or flavor. For example, Cue decides which node(s) to remove in the case of a down-size.
API Approach 1 Pros/Cons
Pros | Cons |
---|---|
|
|
API Approach 2 Pros/Cons
Pros | Cons |
---|---|
|
|