The Horizon project also uses the nova policy.json file to do role based access control (RBAC) on the actions a user can perform. If the defaults are hidden in the code, that makes those checks a lot more difficult to perform. Horizon will then get to duplicate all the hard coded defaults in our code base. Fully understanding UI is not everyone's primary concern, I will just point out that it's a terrible user experience to have 10 actions listed on an instance that will only fail when actually attempted by making the API call.
To accomplish this level of RBAC, Horizon has to maintain a sync'd copy of the nova policy file. The move to centralized policy is something I am very excited about. But this seems to be a move in the opposite direction. I think simply documenting the default values in the policy.json file would be a simpler and more straight-forward approach. I think the defcore resolution is also a documentation issue. David On Tue, Jun 2, 2015 at 10:31 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 06/02/2015 06:22 PM, Sean Dague wrote: > > Nova has a very large API, and during the last release cycle a lot > > of work was done to move all the API checking properly into policy, > > and not do admin context checks at the database level. The result > > is a very large policy file - > > https://github.com/openstack/nova/blob/master/etc/nova/policy.json > > > > This provides a couple of challenges. One of which is in recent > > defcore discussions some deployers have been arguing that the > > existence of policy files means that anything you can do with > > policy.json is valid and shouldn't impact trademark usage, because > > the knobs were given. Nova specifically states this is not ok - > > https://github.com/openstack/nova/blob/master/doc/source/devref/policy > _enforcement.rst#existed-nova-api-being-restricted > > > > > however, we'd like to go a step further here. > > > > What we'd really like is sane defaults for policy that come from > > code, not from etc files. So that a Nova deploy with an empty > > policy.json is completely valid, and does a reasonable thing. > > > > Policy.json would then be just a set > > ofhttp://docs.openstack.org/developer/oslo.policy/api.html#rule-check > > overrides for existing policy. That would make it a lot more clear > > what was changed from the existing policy. > > > > We'd also really like the policy system to be able to WARN when > > the server starts if the policy was changed in some way that could > > negatively impact compatibility of the system, i.e. if functions > > that we felt were essential were turned off. Because the default > > policy is in code, we could have a view of the old and new world > > and actually warn the Operator that they did a weird thing. > > > > Lastly, we'd actually really like to redo our policy to look more > > like resource urls instead of extension names, as this should be a > > lot more sensible to the administrators, and hopefully make it > > easier to think about policy. Which I think means an aliasing > > facility in oslo.policy to allow a graceful transition for users. > > (This may exist, I don't know). > > If I understand your aliasing need correctly, you may want to use > RuleChecks: > http://docs.openstack.org/developer/oslo.policy/api.html#rule-check > > > > > I'm happy to write specs here, but mostly wanted to have the > > discussion on the list first to ensure we're all generally good > > with this direction. > > > > -Sean > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVbdp7AAoJEC5aWaUY1u57/x0H/0G2aGlfNVyUdcflC19sner6 > FobWh/ASS/fBLq2SjDGduieu/voCdvK8XKi4rTncSvcwuKGVkgmJ/G3YiO22ZPyn > kPFWtQjiSadRdmP3WRmMYU4LeHw090Gxq32lBA7knpqon2f/MTHLPZUsnqdmX5R8 > J7zpGEj+nqe9RiWq4kJzwK8niwZTe4FP5+wvc3A+QYNbHNJB5feY5VnGMuUK/4O/ > svsmuNMyAz93GCZL36f+EJoXXQv7+tGtSuImANq505Ae6sXs+Bl7crZul9lkzHo7 > VB/UCbcxa208iw6tiWBh4qP1Y8vBljNjL8ifNbyXj6Y0z3gekEtoUcBQq3T0w5s= > =lBtm > -----END PGP SIGNATURE----- > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
