Open Stack

I think the tasks stuff is something different, though. A task is a
(potentially) long-running operation. So it would be possible for an action
to result in the creation of a task. As the proposal stands today, the
actions we've been looking at are an alternative to the document-oriented
PATCH HTTP verb. There was nearly unanimous consensus that we found "POST
/resources/actions/verb {inputs to verb}" to be a more expressive and
intuitive way of accomplishing some workflows than trying to use JSON-PATCH
documents.


On Tue, Jun 10, 2014 at 4:15 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On Wed, Jun 4, 2014 at 11:54 AM, Sean Dague <sean at dague.net> wrote:
>
>> On 05/30/2014 02:22 PM, Hemanth Makkapati wrote:
>> > Hello All,
>> > I'm writing to notify you of the approach the Glance community has
>> > decided to take for doing functional API.  Also, I'm writing to solicit
>> > your feedback on this approach in the light of cross-project API
>> > consistency.
>> >
>> > At the Atlanta Summit, the Glance team has discussed introducing
>> > functional API in Glance so as to be able to expose operations/actions
>> > that do not naturally fit into the CRUD-style. A few approaches are
>> > proposed and discussed here
>> > <
>> https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api
>> >.
>> > We have all converged on the approach to include 'action' and action
>> > type in the URL. For instance, 'POST
>> > /images/{image_id}/actions/{action_type}'.
>> >
>> > However, this is different from the way Nova does actions. Nova includes
>> > action type in the payload. For instance, 'POST
>> > /servers/{server_id}/action {"type": "<action_type>", ...}'. At this
>> > point, we hit a cross-project API consistency issue mentioned here
>> > <
>> https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis
>> >
>> > (under the heading 'How to act on resource - cloud perform on
>> > resources'). Though we are differing from the way Nova does actions and
>> > hence another source of cross-project API inconsistency , we have a few
>> > reasons to believe that Glance's way is helpful in certain ways.
>> >
>> > The reasons are as following:
>> > 1. Discoverability of operations.  It'll be easier to expose permitted
>> > actions through schemas a json home document living at
>> > /images/{image_id}/actions/.
>> > 2. More conducive for rate-limiting. It'll be easier to rate-limit
>> > actions in different ways if the action type is available in the URL.
>> > 3. Makes more sense for functional actions that don't require a request
>> > body (e.g., image deactivation).
>> >
>> > At this point we are curious to see if the API conventions group
>> > believes this is a valid and reasonable approach.
>> > Any feedback is much appreciated. Thank you!
>>
>> Honestly, I like POST /images/{image_id}/actions/{action_type} much
>> better than ACTION being embedded in the body (the way nova currently
>> does it), for the simple reason of reading request logs:
>>
>
> I agree that not including the action type in the POST body is much nicer
> and easier to read in logs, etc.
>
> That said, I prefer to have resources actually be things that the software
> creates. An action isn't created. It is performed.
>
> I would prefer to replace the term "action(s)" with the term "task(s)", as
> is proposed for Nova [1].
>
> Then, I'd be happy as a pig in, well, you know.
>
> Best,
> -jay
>
> [1] https://review.openstack.org/#/c/86938/
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140610/76bc8cc7/attachment.html>