Open Stack

2016-12-20 11:34 GMT+08:00 Qiming Teng <tengqim at linux.vnet.ibm.com>:

> On Tue, Dec 20, 2016 at 10:14:49AM +0800, Alex Xu wrote:
> > Yea, looks like no consensus at here. Look at the discussion Chris
> pointed
> > to, the "/containers/<ID>/action" sounds a good API for tasks.
>
> Did you mean "/containers/<ID>/actions" ?
>

yea, you are right. sorry about that.


>
> > But we also see the disadvantage for it. When we want to use URL to
> > identifying an action, we found all the actions into a single API. We
> faced
> > this problem multiple times:
>
> Then we should stop identifying actions based on URL. :)
> The following URL for representing a 'pause' action is really ugly:
>
>    /containers/<ID>/pause
>
> First of all, 'pause' is a verb. I cannot persuade myself that doing a
> POST to a verb is a ReST call. And I cannot do a 'GET', 'DELETE' not
> due to I'm not an admin ... rather, it is because I cannot explain what
> it means by 'deleting a pause'.
>
> > 1. In the beginning of thinking about capability discovery, an idea is
> > about returning a list of URLs if the user have the ability to execute.
> But
> > found that all the actions are into single URL
> > 2. Before there is an idea about if the policy rule name is the URL, then
> > the user can easy to know the mapping between policy rule and API. The
> same
> > problem, all the actions into single URL
>
> Neither capability discovery or policy enforcement should be based
> solely on URL, IMO. Capabilities should have its own resource
> representation if possible. As for policy, it still seems an over
> simplification of authorization. There many scenarios where users
> want a finer granularity of access control. Even if we want to stick to
> the policy.json approach today, we can somehow improve the checking, for
> example:
>
>    "containers:action:reboot": "role:owner"
>
> Similarly, auditing and logging can be done in the same way.
>
> > 3. Before think about using OpenAPI(swagger) to generate api doc, but the
> > OpenAPI spec didn't support multiple "POST containers/<ID>/action", that
> > means we need to put all the actions into single entry. That makes the
> > generated doc unreadable.
>
> That is history now. We are moving to the api-ref way of documenting
> APIs. Don't tell me there are plans to migrate it back, :D
>

Yea, just as I said, none of above problems block on this issue. It is also
hard to say this is key issue lead to another solution. I just provide some
info if people really care about this issue we met before.


>
> - Qiming
> > But yes, that doesn't means we block on this problem. Finally we go to
> > another direction. So just input something we met before for your
> > consideration.
> >
> > Thanks
> > Alex
> >
> > 2016-12-19 19:57 GMT+08:00 Chris Dent <cdent+os at anticdent.org>:
> >
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20161220/f54e9f9f/attachment.html>