<div dir="ltr">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.<div><br></div><div>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.<br><div><br></div><div>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.</div><div><br></div><div>David </div><div><br></div><div> </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 2, 2015 at 10:31 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<span class=""><br>
On 06/02/2015 06:22 PM, Sean Dague wrote:<br>
> Nova has a very large API, and during the last release cycle a lot<br>
> of work was done to move all the API checking properly into policy,<br>
> and not do admin context checks at the database level. The result<br>
> is a very large policy file -<br>
> <a href="https://github.com/openstack/nova/blob/master/etc/nova/policy.json" target="_blank">https://github.com/openstack/nova/blob/master/etc/nova/policy.json</a><br>
><br>
> This provides a couple of challenges. One of which is in recent<br>
> defcore discussions some deployers have been arguing that the<br>
> existence of policy files means that anything you can do with<br>
> policy.json is valid and shouldn't impact trademark usage, because<br>
> the knobs were given. Nova specifically states this is not ok -<br>
> <a href="https://github.com/openstack/nova/blob/master/doc/source/devref/policy
_enforcement.rst#existed-nova-api-being-restricted" target="_blank">https://github.com/openstack/nova/blob/master/doc/source/devref/policy<br>
_enforcement.rst#existed-nova-api-being-restricted</a><br>
><br>
><br>
however, we'd like to go a step further here.<br>
><br>
> What we'd really like is sane defaults for policy that come from<br>
> code, not from etc files. So that a Nova deploy with an empty<br>
> policy.json is completely valid, and does a reasonable thing.<br>
><br>
> Policy.json would then be just a set<br>
</span>> ofhttp://<a href="http://docs.openstack.org/developer/oslo.policy/api.html#rule-check" target="_blank">docs.openstack.org/developer/oslo.policy/api.html#rule-check</a><br>
<span class="">> overrides for existing policy. That would make it a lot more clear<br>
> what was changed from the existing policy.<br>
><br>
> We'd also really like the policy system to be able to WARN when<br>
> the server starts if the policy was changed in some way that could<br>
> negatively impact compatibility of the system, i.e. if functions<br>
> that we felt were essential were turned off. Because the default<br>
> policy is in code, we could have a view of the old and new world<br>
> and actually warn the Operator that they did a weird thing.<br>
><br>
> Lastly, we'd actually really like to redo our policy to look more<br>
> like resource urls instead of extension names, as this should be a<br>
> lot more sensible to the administrators, and hopefully make it<br>
> easier to think about policy. Which I think means an aliasing<br>
> facility in oslo.policy to allow a graceful transition for users.<br>
> (This may exist, I don't know).<br>
<br>
</span>If I understand your aliasing need correctly, you may want to use<br>
RuleChecks:<br>
<a href="http://docs.openstack.org/developer/oslo.policy/api.html#rule-check" target="_blank">http://docs.openstack.org/developer/oslo.policy/api.html#rule-check</a><br>
<span class=""><br>
><br>
> I'm happy to write specs here, but mostly wanted to have the<br>
> discussion on the list first to ensure we're all generally good<br>
> with this direction.<br>
><br>
> -Sean<br>
><br>
</span>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQEcBAEBCAAGBQJVbdp7AAoJEC5aWaUY1u57/x0H/0G2aGlfNVyUdcflC19sner6<br>
FobWh/ASS/fBLq2SjDGduieu/voCdvK8XKi4rTncSvcwuKGVkgmJ/G3YiO22ZPyn<br>
kPFWtQjiSadRdmP3WRmMYU4LeHw090Gxq32lBA7knpqon2f/MTHLPZUsnqdmX5R8<br>
J7zpGEj+nqe9RiWq4kJzwK8niwZTe4FP5+wvc3A+QYNbHNJB5feY5VnGMuUK/4O/<br>
svsmuNMyAz93GCZL36f+EJoXXQv7+tGtSuImANq505Ae6sXs+Bl7crZul9lkzHo7<br>
VB/UCbcxa208iw6tiWBh4qP1Y8vBljNjL8ifNbyXj6Y0z3gekEtoUcBQq3T0w5s=<br>
=lBtm<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>