Open Stack

Looping this into the operator's list, too!

On Wed, Jan 18, 2017 at 2:13 PM, Lance Bragstad <lbragstad at gmail.com> wrote:

> 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/941c68df/attachment.html>