[openstack-dev] [Glance][TC] Glance Functional API and Cross-project API Consistency
Jay Pipes
jaypipes at gmail.com
Tue Jun 24 16:55:00 UTC 2014
On 06/11/2014 02:34 AM, Mark Washenberger wrote:
> 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.
Why do tasks necessarily mean the operation is long-running? As
mentioned before to Brian R, just have the deactivation action be a
task. There's no need to create a new faux-resource called 'action', IMO...
Best,
-jay
> On Tue, Jun 10, 2014 at 4:15 PM, Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>> wrote:
>
> On Wed, Jun 4, 2014 at 11:54 AM, Sean Dague <sean at dague.net
> <mailto: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
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list