Open Stack

On 2/15/15, 2:35 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>On 02/15/2015 01:13 PM, Brian Rosmaita wrote:
>> On 2/15/15, 10:10 AM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>>
>>> On 02/15/2015 01:31 AM, Brian Rosmaita wrote:
>>>> This is a follow-up to the discussion at the 12 February API-WG
>>>> meeting [1] concerning "functional" API in Glance [2].  We made
>>>> some progress, but need to close this off so the spec can be
>>>> implemented in Kilo.
>>>>
>>>> I believe this is where we left off: 1. The general consensus was
>>>> that POST is the correct verb.
>>>
>>> Yes, POST is correct (though the resource is wrong).
>>>
>>>> 2. Did not agree on what to POST.  Three options are in play: (A)
>>>> POST /images/{image_id}?action=deactivate POST
>>>> /images/{image_id}?action=reactivate
>>>>
>>>> (B) POST /images/{image_id}/actions with payload describing the
>>>> action, e.g., { "action": "deactivate" } { "action": "reactivate"
>>>> }
>>>>
>>>> (C) POST /images/{image_id}/actions/deactivate POST
>>>> /images/{image_id}/actions/reactivate
>>>
>>> d) POST /images/{image_id}/tasks with payload: { "action":
>>> "deactivate|activate" }
>>>
>>> An action isn't created. An action is taken. A task is created. A
>>> task contains instructions on what action to take.
>>
>> The Images API v2 already has tasks (schema available at
>> /v2/schemas/tasks ), which are used for long-running asynchronous
>> operations (right now, image import and image export).  I think we
>> want to keep those distinct from what we're talking about here.
>>
>> Does something really need to be created for this call?  The idea
>> behind the "functional" API was to have a place for things that don't
>> fit neatly into the CRUD-centric paradigm.  Option (C) seems like a
>> good fit for this.
>
>Why not just use the existing tasks/ interface, then? :) Seems like a
>perfect fit to me.

The existing tasks/ interface is kind of heavyweight.  It provides a
framework for asynchronous operations.  It's really not appropriate for
this purpose.

cheers,
brian