Cue/api1vsapi2
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.
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 node flavor and number of nodes respectively. This design minimizes internal per-node specific configuration to the user and therefore lends well for a messaging deployment system that will
API Approach 1 Pros/Cons
Pros | Cons |
---|---|
|
|
API Approach 2 Pros/Cons
Pros | Cons |
---|---|
|
|