Open Stack

Ruan,

Good question! I should clarify that there would be no *default* policy
file to maintain in the project source code, like in keystone currently
[0]. All policy defaults would be coded into the project. Nova has already
taken this approach with their policy file [1], which leaves them with
nothing to maintain in tree (notice the absence of a sample policy file)
[2]. A deployer can still customize policy by using a policy.json file, and
those rules are treated as overrides for the defaults in code.

[0] https://github.com/openstack/keystone/blob/master/etc/policy.json
[1] https://github.com/openstack/nova/blob/master/nova/policies/servers.py
[2] https://github.com/openstack/nova/tree/master/etc/nova

On Thu, Jan 19, 2017 at 8:35 AM, <ruan.he at orange.com> wrote:

> Hi Lance,
>
> Your option 3 is not clear for me.
>
> You say that ‘The result would 0 policy files to maintain in tree and
> everything would be in code.’ Without this file, how can we define
> policies? Can user configure policies?
>
> Ruan
>
>
>
> *From:* Lance Bragstad [mailto:lbragstad at gmail.com]
> *Sent:* mercredi 18 janvier 2017 23:16
> *To:* OpenStack Development Mailing List (not for usage questions);
> openstack-operators at lists.openstack.org
> *Subject:* Re: [openstack-dev] [keystone] 2017-1-11 policy meeting
>
>
>
> 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
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170119/2868bf12/attachment.html>