Yesterday, in the keystone meeting [0], we talked about what we want to do with the remaining scope and default roles work in keystone. With all the patches proposed, merged, and reviewed around this work, I thought a summary might be beneficial for everyone. Besides, despite my best efforts I still don't share the same polarity with buses. So, getting this information out is probably best for everyone, including other developers looking to do something similar in their services. For context, we landed a major refactor in Rocky allowing keystone to consume different scopes (e.g., project, domain, and system), making the entire keystone API more self-serviceable. We also decided to implement default roles since we already planned on making policy changes, which gives us things like read-only support out-of-the-box. Right around the time Stein opened for development, I took an initial pass at opening bugs to track this work. Turns out refactoring the authorization of an entire API is a significant amount of work, especially to track in a single bug report [1]. We kept new bug reports specific to one resource at a time. If the API made sense to expose with multiple scopes (e.g., allowing project users, domain users, and system users to all access the API) we opened a bug, specifically to implement those scopes. We tagged these bugs with the `system-scope` tag in Launchpad [2]. Resources in keystone that needed to implement support for default roles required separate bug reports. We tagged these bugs with the `default-roles` tag in Launchpad [3]. All bugs that fell into these two camps also received the `policy` tag. Altogether, we broke the work to implement scope types and default roles across keystone's API into 39 different bug reports [4]. Of those 39 bug reports, 13 are for correcting scope behavior, which exposes more functionality to end users, safely. The remaining 26 are for implementing default roles, which gives us things like read-only support. Of the 13 scope bugs we: - fixed 2 - have 7 in progress - have 4 awaiting fixes Note that some of the fixes above are dependent on a devstack patch to correct what tempest assumes about certain scopes [5]. Of the 26 bugs for default roles we: - fixed 14 - have 12 awaiting fixes In total, of the 39 bugs we opened for the entirety of this work in Stein we: - fixed 16 (~41%) - have 7 in progress (~17%) - have 16 awaiting fixes (~41%) I took one final pass through all of keystone's policies yesterday to make sure we have everything captured in bug reports. If you see something that I missed, let me know or open a bug report so that we can capture the information. To highlight the work required to get us this far, as of e8d9791c6ecea1bf5fd4878b57c892b0a4c8a19e, we've merged [6] 259 tests [7]. These tests are reused to execute 593 functional protection tests [8] that exercise the default roles against various scopes and ensures users can do what we expect. These number don't include the patches that are still in review [9] that implement more protection testing. I think it's safe to say that we're not going to get the remaining work merged into Stein. However, are there specific resources we want to prioritize for Stein of the remaining bug reports [10]? Thanks, Lance [0] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-03-05-16... [1] https://bugs.launchpad.net/keystone/+bug/968696 [2] http://tinyurl.com/y3ux97ma [3] http://tinyurl.com/y3y779e8 [4] http://tinyurl.com/y649w43n [5] https://review.openstack.org/#/c/624794/ [6] https://review.openstack.org/#/q/status:merged+project:openstack/keystone+br...) [7] grep -R 'def test_' keystone/tests/unit/protection/ | wc -l [8] tox -e py37 -- keystone.tests.unit.protection [9] https://review.openstack.org/#/q/status:open+project:openstack/keystone+bran...) [10] http://tinyurl.com/y4vwdsjz