On 26/07/12 14:47 +0100, Angus Thomas wrote:
On 07/17/2012 08:13 PM, Richard Su wrote:
conductor/api/deployments
- 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 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
conductor/api/deployments/$id/instances conductor/api/instances
- Stop an instance
- Start an instance
- List all instances for a given deployment
- List all instances I can control across all deployments - TBD
- Show instance, status, ip address, ssh keys, etc..
I think this last point, "Show instance status" is going to be very important. People are asking about how they can plug Conductor into external monitoring infrastructure, and trigger events/alerts etc., based on the state of instances and deployments. A complete instance/deployment monitoring API is probably too much of a stretch for this proposal to accommodate, but I'm sure there will be significant interest in whatever state reporting we add to the API.
Angus
While I agree with this, I would suggest we use caution in what functionality we expose, so as not to overlap with the actual event api that we have. We should probably consider whether 'monitor api' is a separate entity from the standard rest api we are implementing here _and_ if it is different from the event api (further build out of same described in the arch thread nobody replied to, see list). The main point here is to make sure we keep our APIs focused and not pollute them for the sake of trying to please everyone at once.
-j