RFC: Deployable, Deployment, and Instance API

Scott Seago sseago at redhat.com
Wed Jul 25 13:55:24 UTC 2012


On 07/24/2012 12:42 PM, Jason Guiditta wrote:
> On 24/07/12 15:28 +0200, Jan Provaznik wrote:
>>>>>> 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.
>>>>
>>>> My thought on this was that they should all just be treated as
>>>> updates, iow, PUT the desired changes/fields in the request to
>>>> initiate the desired action.  Having a separate methods doesnt feel
>>>> like it fits into REST properly to me. If there is disagreement here,
>>>> I think this is a good place to iron it out, as the pattern needs to
>>>> be established and made consistent now, before things get even more
>>>> complex (like adding other layers of api, etc).
>>>>
>>> Hmm. The thing is it's not really an update. To 'stop' an instance 
>>> isn't
>>> an update to the 'state' -- the state won't change until the action is
>>> done. We're explicitly requesting that an action occur on an instance
>>> ("please stop this now", "please start this tomorrow morning"), which,
>>> REST or not, doesn't feel like an update -- it's a request to do
>>> something that might (eventually) result in an update. Surely there's a
>>> REST-appropriate way of doing this that doesn' obscure the fact that
>>> it's not really an update.
>>>
>>> Scott
>>>
>>
>> There might be a (nested) resource for these actions, e.g. 
>> instanceaction. This resource would have only create action:
>>
>> So requests would look like this:
>> POST instance/id/instanceaction?type=restart
>> POST instance/id/instanceaction?type=start
>> POST instance/id/instanceaction?type=stop
>>
>> Jan
>
> Yes, I think something more along these lines makes sense, I was
> thinking something a little more generic, but we can work through impl
> details as needed.  My thought was something like curl -X POST 
> --header "Accept: application/xml" --header \
> "Content-Type: application/xml" http://localhost:3000/action
> --data \
> "<action>
> <target_type>instance</>
> <target_id>1</>
> <perform>start</>
> </action>"
>
> In this way, you can initiate an action on any object that supports
> actions, and the system should perform the desired work.  Of course,
> this also implies that the user can request a list of valid actions
> for a given object type, but that should be pretty easily accomplished
> with something like:
> curl --header "Accept: application/xml" http://localhost:3000/action \
> --data-urlencode "target_type=instance"
>
> possibly with a parameter like 'valid=options' or something?  Scott,
> do these 2 variations of the same idea make more sense to you?
>
> -j
I think this makes sense, yes. I know at one point we had a model method 
that returned a list of valid actions which, in a much earlier 
iteration, the UI actually used. As we're improving the UI again (and 
adding more valid actions now), we'll need this 'valid action list' in 
the UI at some point as well, so having it in the API here makes some sense.

Scott




More information about the aeolus-devel mailing list