On 06/11/2014 12:25 AM, Brian Rosmaita wrote:
> 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].
Glance already uses "tasks" in the v2 URL for creating resources that
represent long-running asynchronous processes (import, export, cloning),
so that terminology is already taken. (The documentation is lagging a
bit behind the code on tasks, though.)
The aim here is to introduce something that doesn't fit cleanly into a
CRUD-centric view. For example, a cloud provider may need to put an
imported (or otherwise problematic) image into "deactivated" status
while the image is being investigated for some malicious stuff built
into it [2].
So just have a task that does deactivation... there's no need to create
this new "action" resource IMO.
Image status, however, is never set directly by users or
admins; image status transitions are handled entirely by Glance. (You
don't delete an image by updating its status to be 'deleted'; rather,
its status becomes 'deleted' as a result of a DELETE request). Using an
Images v2 PATCH call in this context would be misleading because we're
not modifying the image's status--we can't. We're asking Glance to take
an action with respect to an image, the result of which will be that the
image will be deactivated (or reactivated), and Glance will modify the
image's status accordingly.
cheers,
brian
[1] https://review.openstack.org/#/c/86938/
[2] https://wiki.openstack.org/wiki/Glance-deactivate-image
------------------------------------------------------------------------
*From:* Jay Pipes [jaypi...@gmail.com]
*Sent:* Tuesday, June 10, 2014 7:15 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Glance][TC] Glance Functional API and
Cross-project API Consistency
On Wed, Jun 4, 2014 at 11:54 AM, Sean Dague <s...@dague.net
<mailto:s...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
