On 07/17/2012 03:13 PM, Richard Su wrote:
Hi,
Below is an outline of REST API endpoints that we would need to
implement to allow users to automate further their interactions with
Conductor. The endpoints follows the actions available in the current
Conductor UI flow.
The contents is also up this wiki page
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Deployable_Dep...
Endpoints
conductor/api/deployables
Is it safe to assume that all of the API will also work
on the standard
controller action URLs (i.e. /conductor/deployables, etc)? If we're
doing this as planned, using the same controller actions that we use for
the UI, then in most cases /conductor/api/foo will just be a route that
returns /conductor/foo. The regular actions will do the normal UI html
generation in the html render block, and the API rendering in the xml
and json blocks
1. Create given name, catalog id(s), and deployable xml.
Deployable xml is validated before it can be saved.
Reference for Deployable XMLs -
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Deployable_XML
2. Show a deployable
3. Index of deployables - list name and href to id
This takes an optional
catalog_id -- i.e. either list deployables in a
catalog, or list all deployables (filtered by permission of course).
That part is already in the controller logic, though.
4. Delete a deployable
5. Edit a deployable
PUT new deployable xml, respond with 200 and newly saved object
Allow update of name and catalog ids
The images defined in the deployable xml must exist, but they need not
be built or pushed. If there are multiple assemblies, any missing
image should fail the validation.
conductor/api/deployments
And this should also work under /conductor/deployments
since the
controller is there anyway. Same comment applies to the other object
types below as well.
1. Create given name, deployable id, and optional realm
All images defined in the deployable must be built and pushed to
the choosen realm
Launches instances
Don't forget pool -- that's required -- you'll
see that when you add the
api stuff to the existing controller action.
2. Show a deployment and its instances
Each instance is listed with name and a link to the real object
3. Index of deployments
4. Delete a deployment
5. Edit a deployment - not available
What about other deployment actions? 'stop', 'start' (once we can
re-start stopped ones), 'reboot', etc.
conductor/api/deployments/$id/instances
conductor/api/instances
1. Stop an instance
2. Start an instance
3. List all instances for a given deployment
4. List all instances I can control across all deployments - TBD
5. Show instance, status, ip address, ssh keys, etc..
conductor/api/realms
1. Create, map to provider, map to provider realm
2. Show a realm
3. List all realms
4. Delete a realm
5. Edit a realm and mappings
conductor/api/provider_accounts/$id/realms
1. List from provider accounts
conductor/api/hardware_profiles/
CRUD
conductor/api/catalogs
CRUD
conductor/api/pools
CRUD, catalogs are mapped to a pool
---
Reference
Initial planning discussion -
http://etherpad-aeolusproject.rhcloud.com/p/deployables_and_instance_api