<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi, guys<br>
<br>
There are some BPs working on improve the usability of API policy.
Initially<br>
those BP just for v2.1/v3 API. For v2 API, we just want to it keep
the same<br>
as before.<br>
<br>
But in Juno design summit, we get some complain about policy is hard
to use.<br>
(<a class="moz-txt-link-freetext" href="https://etherpad.openstack.org/p/juno-nova-devops">https://etherpad.openstack.org/p/juno-nova-devops</a>)<br>
I guess those guys is complain for v2 API. So I'm thinking of
whether we should<br>
enable those improvment for v2 API too. I want to hear your guys and
CD<br>
people's suggestion. To ensure we should enable those for V2 API.<br>
<br>
The main propose of improve policy is:<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Policy should be enforced at REST API layer
<a class="moz-txt-link-freetext" href="https://review.openstack.org/92005">https://review.openstack.org/92005</a><br>
<br>
In this propose we remove the compute-api layer policy checks for v3
API, and<br>
move policy checks into API layer for v2 API. So only v3 API can get
the benefit.<br>
V2 API still have two policy checks for same API.<br>
<br>
For example:<br>
At API layer: "compute_extension:admin_actions:pause":
"rule:admin_or_owner"<br>
At compute API layer: "compute:pause": ""<br>
<br>
There is pros/cons of enable for v2 API as below:<br>
<br>
Pros:<br>
* V2 API user can get the benefit from those improvement. We still
have some<br>
user use V2 API before we release V2.1/V3.<br>
<br>
* We don't need make the code back-compatibility for v2 API. That
make the<br>
code looks mess.<br>
<br>
For example:<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/65071/5/nova/api/openstack/compute/contrib/shelve.py">https://review.openstack.org/#/c/65071/5/nova/api/openstack/compute/contrib/shelve.py</a><br>
There are two policy checks code for one API. One is used for
extension (line 84),<br>
another one for keep compatibility (line 85).<br>
<br>
(There is another method that won't make the code mess and we can
support<br>
back-compatibility. It is that we didn't remove the compute api
layer policy code,<br>
then we just skip the policy check for v3 API. After v2 API
deprecated, we clean<br>
up those compute api layer policy code.)<br>
<br>
Cons:<br>
* Maybe V2 API user didn't have too much pain on this. And we will
have V2.1/V3 API,<br>
V2 will be deprecated. If we change those, this may become extra
burden for some<br>
operator user upgrade their policy config file when upgrade nova
code.<br>
<br>
* The risk of touch existed v2 API code.<br>
<br>
And there are other minor improvement propose for API policy:<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/92325">https://review.openstack.org/92325</a><br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/92326">https://review.openstack.org/92326</a><br>
<br>
I think after make decision for first propose, then I think those
two propose can<br>
just follow the decision.<br>
<br>
Thanks<br>
Alex<br>
</body>
</html>