On Tue, Jun 2, 2015 at 12:09 PM, Adam Young <ayo...@redhat.com> wrote:
> Since this a cross project concern, sending it out to the wider mailing > list: > > We have a sub-effort in Keystone to do better access control policy (not > the Neutron or Congress based policy efforts). > > I presented on this at the summit, and the effort is under full swing. We > are going to set up a subteam meeting for this, but would like to get some > input from outside the Keystone developers working on it. In particular, > we'd like input from the Nova team that was thinking about hard-coding > policy decisions in Python, and ask you, instead, to work with us to come > up with a solution that works for all the service. > > I want to be sure we look at what Nova is presenting here. While building policy into python may not (on the surface) look like an approach that is wanted due to it restricting the flexibility that we've had with policy.json, I don't want to exclude the concept without examination. If there is a series of base level functionality that is expected to work with Nova in all cases - is that something that should be codified in the policy rules? This doesn't preclude having a mix between the two approaches (allowing custom roles, etc, but having a baseline for a project that is a known quantity that could be overridden). Is there real value (from a UX and interoperability standpoint) to have everything 100% flexible in all the ways? If we are working to redesign how policy works, we should be very careful of excluding the (more) radical ideas without consideration. I'd argue that dynamic policy does fall on the opposite side of the spectrum from the Nova proposal. In truth I'm going to guess we end up somewhere in the middle. > If you are interested in being part of this effort, there is a Trello > board set up here: > > https://trello.com/b/260v4Gs7/dynamic-policy > > It should be world readable. I will provide you write access if you are > interested in contributing. In addition, let me know what your constraints > are in setting up a weekly meeting and I will try to accommodate. Right > now, the people involved are primarily East-Coast of the Western Hemisphere > and Europe, and the meeting time will likely be driven by that. > > I definitely want to encourage this to be a cross-project / horizontal effort as this will impact everything within OpenStack. Cheers, --Morgan
__________________________________________________________________________ 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
