Looping this into the operator's list, too! On Wed, Jan 18, 2017 at 2:13 PM, Lance Bragstad <lbrags...@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 <lbrags...@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 >> > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
