On 26/07/12 14:47 +0100, Angus Thomas wrote:
On 07/17/2012 08:13 PM, Richard Su wrote:
>
>conductor/api/deployments
>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
>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
>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..
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