[openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
John Garbutt
john at johngarbutt.com
Wed Jun 3 09:14:18 UTC 2015
On 2 June 2015 at 23:48, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:
> On Tue, 2015-06-02 at 16:16 -0600, David Lyle wrote:
>> 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.
Yeah, thats totally nuts.
Policy discovery is the fix to this tight coupling I guess.
>> 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.
We are super worried about this, at least I am.
Its a bad API user experience.
However, we are still getting the plumbing sorted to let us fix that.
And no one has stepped up to own writing up the proposed solutions (yet...?)
> For the record, the discussion at the summit also touched on the
> discoverability of the policy affecting a given user/API. I don't
> believe we considered the ordering between that and the defaults feature
> we suggested, but I believe we can code a defaults mechanism to
> dynamically generate an output file in the interim (as is done for
> configuration now), which may improve the situation from Horizon's
> standpoint, until the discoverability piece is in place.
We were planning on having all the default lines commented out, but we
can sure skip that if it helps horizon until the discoverable policy
is complete. There should be something that works out there.
Honestly, it probably has to be more than policy, the capabilities of
the system as its configured, are also an important input into this.
It seems harsh to assume the deployer has to setup their policy to
accuratly reflect what the system is capable of. I hope that gets
unified, possibly via dynamic policy "defaults", or ideally something
less evil.
Thanks,
John
More information about the OpenStack-dev
mailing list