<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-12-20 11:34 GMT+08:00 Qiming Teng <span dir="ltr"><<a href="mailto:tengqim@linux.vnet.ibm.com" target="_blank">tengqim@linux.vnet.ibm.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Tue, Dec 20, 2016 at 10:14:49AM +0800, Alex Xu wrote:<br>
> Yea, looks like no consensus at here. Look at the discussion Chris pointed<br>
> to, the "/containers/<ID>/action" sounds a good API for tasks.<br>
<br>
</span>Did you mean "/containers/<ID>/actions" ?<br></blockquote><div><br></div><div>yea, you are right. sorry about that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> But we also see the disadvantage for it. When we want to use URL to<br>
> identifying an action, we found all the actions into a single API. We faced<br>
> this problem multiple times:<br>
<br>
</span>Then we should stop identifying actions based on URL. :)<br>
The following URL for representing a 'pause' action is really ugly:<br>
<br>
   /containers/<ID>/pause<br>
<br>
First of all, 'pause' is a verb. I cannot persuade myself that doing a<br>
POST to a verb is a ReST call. And I cannot do a 'GET', 'DELETE' not<br>
due to I'm not an admin ... rather, it is because I cannot explain what<br>
it means by 'deleting a pause'.<br>
<span class="gmail-"><br>
> 1. In the beginning of thinking about capability discovery, an idea is<br>
> about returning a list of URLs if the user have the ability to execute. But<br>
> found that all the actions are into single URL<br>
> 2. Before there is an idea about if the policy rule name is the URL, then<br>
> the user can easy to know the mapping between policy rule and API. The same<br>
> problem, all the actions into single URL<br>
<br>
</span>Neither capability discovery or policy enforcement should be based<br>
solely on URL, IMO. Capabilities should have its own resource<br>
representation if possible. As for policy, it still seems an over<br>
simplification of authorization. There many scenarios where users<br>
want a finer granularity of access control. Even if we want to stick to<br>
the policy.json approach today, we can somehow improve the checking, for<br>
example:<br>
<br>
   "containers:action:reboot": "role:owner"<br>
<br>
Similarly, auditing and logging can be done in the same way.<br>
<span class="gmail-"><br>
> 3. Before think about using OpenAPI(swagger) to generate api doc, but the<br>
> OpenAPI spec didn't support multiple "POST containers/<ID>/action", that<br>
> means we need to put all the actions into single entry. That makes the<br>
> generated doc unreadable.<br>
<br>
</span>That is history now. We are moving to the api-ref way of documenting<br>
APIs. Don't tell me there are plans to migrate it back, :D<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
- Qiming<br>
</font></span><span class="gmail-im gmail-HOEnZb">> But yes, that doesn't means we block on this problem. Finally we go to<br>
> another direction. So just input something we met before for your<br>
> consideration.<br>
><br>
> Thanks<br>
> Alex<br>
><br>
> 2016-12-19 19:57 GMT+08:00 Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>>:<br>
><br>
<br>
<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>