Jump to: navigation, search

Cue/api1vsapi2

< Cue
Revision as of 01:29, 15 December 2014 by Dagnello (talk | contribs) (API Approach 2 Summary)

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