Open Stack

Hi, guys

There are some BPs working on improve the usability of API policy. Initially
those BP just for v2.1/v3 API. For v2 API, we just want to it keep the same
as before.

But in Juno design summit, we get some complain about policy is hard to use.
(https://etherpad.openstack.org/p/juno-nova-devops)
I guess those guys is complain for v2 API. So I'm thinking of whether we 
should
enable those improvment for v2 API too. I want to hear your guys and CD
people's suggestion. To ensure we should enable those for V2 API.

The main propose of improve policy is:
Policy should be enforced at REST API layer 
https://review.openstack.org/92005

In this propose we remove the compute-api layer policy checks for v3 
API, and
move policy checks into API layer for v2 API. So only v3 API can get the 
benefit.
V2 API still have two policy checks for same API.

For example:
At API layer: "compute_extension:admin_actions:pause": "rule:admin_or_owner"
At compute API layer: "compute:pause": ""

There is pros/cons of enable for v2 API as below:

Pros:
* V2 API user can get the benefit from those improvement. We still have some
user use V2 API before we release V2.1/V3.

* We don't need make the code back-compatibility for v2 API. That make the
code looks mess.

For example:
https://review.openstack.org/#/c/65071/5/nova/api/openstack/compute/contrib/shelve.py
There are two policy checks code for one API. One is used for extension 
(line 84),
another one for keep compatibility (line 85).

(There is another method that won't make the code mess and we can support
back-compatibility. It is that we didn't remove the compute api layer 
policy code,
then we just skip the policy check for v3 API. After v2 API deprecated, 
we clean
up those compute api layer policy code.)

Cons:
* Maybe V2 API user didn't have too much pain on this. And we will have 
V2.1/V3 API,
V2 will be deprecated. If we change those, this may become extra burden 
for some
operator user upgrade their policy config file when upgrade nova code.

* The risk of touch existed v2 API code.

And there are other minor improvement propose for API policy:
https://review.openstack.org/92325
https://review.openstack.org/92326

I think after make decision for first propose, then I think those two 
propose can
just follow the decision.

Thanks
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140530/26c6a945/attachment.html>