Difference between revisions of "Sahara/api-v2"
< Sahara
(Created page with "Refactoring the existing Savanna V1 api, making it easier for the user and separating the concerns of the user and deployer. <big>DEPLOYER</big> = Person or entity who deploy...") |
|||
Line 16: | Line 16: | ||
## Will help with the why not Heat argument. | ## Will help with the why not Heat argument. | ||
# Nomenclature change of node_groups to roles. | # Nomenclature change of node_groups to roles. | ||
− | # | + | # Tie images to just node groups and not have it at the cluster create level. |
+ | # Make volume components optional or as a extension. | ||
=== Accepted List of Changes === | === Accepted List of Changes === |
Revision as of 18:15, 22 August 2013
Refactoring the existing Savanna V1 api, making it easier for the user and separating the concerns of the user and deployer.
DEPLOYER = Person or entity who deploys and manages an Openstack installation and Savanna. Responsible for setup, configuration and management of Savanna.
USER = End Users who access the Savanna REST API via a http client, python-savannaclient or Savanna Horizon Dashboard.
High Level overview of Proposed changes
- Refactor the format of the error response
- Update the response codes and error response codes to reflect existing rest patterns.
- Let's not expose the plugins directly via the rest API, instead expose services that are supported by the plugins.
- This allows a plugin to support more than one type of service.
- The user it not exposed to the backend.
- Remove the images api.
- Savanna should be building a higher level service that abstracts the concepts on images from users.
- Expose services to users and manage plugins and images on the backend.
- Will help with the why not Heat argument.
- Nomenclature change of node_groups to roles.
- Tie images to just node groups and not have it at the cluster create level.
- Make volume components optional or as a extension.