On 2/15/15, 2:35 PM, "Jay Pipes" <[email protected]> wrote: >On 02/15/2015 01:13 PM, Brian Rosmaita wrote: >> On 2/15/15, 10:10 AM, "Jay Pipes" <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
