RFC: Deployable, Deployment, and Instance API

Scott Seago sseago at redhat.com
Thu Jul 19 17:51:59 UTC 2012


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_Deployment_and_Instance_API
>
>
> 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
>




More information about the aeolus-devel mailing list