Open Stack

Thanks to Morgan in today's policy meeting [0], we were able to shed some
light on the reasons for keystone having two policy files. The main reason
a second policy file was introduced was to recenter RBAC around concepts
introduced in the V3 API. The problem was that the policy file that came
later [1] wasn't a drop in replacement for the initial one because it
required new roles in order to work properly. Switching to the newer policy
file by default would break deployers who did nothing but implement the
basic RBAC roles required by the initial version [2]. At the time there was
no real way to "migrate" from one policy file to another, so two were
maintained in tree.

Consolidating to a single file, or set of defaults, has benefits for
maintainers and deployers, so we covered paths to accomplish that. We were
able to come up with three paths forward.

   1. Drop support for the original/initial policy file and only maintain
   policy.v3cloudsample.json
   2. Leverage `keystone-manage bootstrap` to create the new roles required
   by policy.v3cloudsample.json
   3. Codify the existing policy file using oslo.policy as a vehicle to
   introduce new defaults from policy.v3cloudsample.json

Everyone seemed to agree the 1st option was the most painful for everyone.
Option 2 (and maybe 3) would more than likely require some sort of upgrade
documentation that describes the process.

Without swaying anyone's opinion, I think I tend to lean towards option 3
because it sounds similar to what nova has done, or is going to do. After
talking to John Garbutt about some of their nova work, it sounded like one
of their next steps was to re-evaluate all RBAC roles/rules now that they
have them in code. If they come across an operation that would benefit from
a different default value, they can use oslo.policy to deprecate or propose
a new default (much like how we use oslo.config for changing or deprecating
configuration values today). From a keystone perspective, this would
effectively mean we would move what we have in policy.json into code, then
do the same exercise with policy.v3cloudsample.json. The result would 0
policy files to maintain in tree and everything would be in code. From
there - we can work with other projects to standardize on what various
roles mean across OpenStack (hopefully following some sort of guide or
document).

I'm excited to hear what others think of the current options, or if there
is another path forward we missed.


[0] http://eavesdrop.openstack.org/meetings/policy/
2017/policy.2017-01-18-16.00.log.html
[1]
https://github.com/openstack/keystone/blob/7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.v3cloudsample.json
[2]
https://github.com/openstack/keystone/blob/7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.json

On Wed, Jan 11, 2017 at 11:28 AM, Lance Bragstad <lbragstad at gmail.com>
wrote:

> Hey folks,
>
> In case you missed the policy meeting today, we had a good discussion [0]
> around incorporating keystone's policy into code using the Nova approach.
>
> Keystone is in a little bit of a unique position since we maintain two
> different policy files [1] [2], and there were a lot of questions around
> why we have two. This same topic came up in a recent keystone meeting, and
> we wanted to loop Henry Nash into the conversation, since I believe he
> spearheaded a lot of the original policy.v3cloudsample work.
>
> Let's see if we can air out some of that tribal knowledge and answer a
> couple questions.
>
> What was the main initiative for introducing policy.v3cloudsample.json?
>
> Is it possible to consolidate the two?
>
>
> [0] http://eavesdrop.openstack.org/meetings/policy/
> 2017/policy.2017-01-11-16.00.log.html
> [1] https://github.com/openstack/keystone/blob/master/etc/policy.
> v3cloudsample.json
> [2] https://github.com/openstack/keystone/blob/master/etc/policy.json
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170118/57188f6a/attachment-0001.html>