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.00.log.html#l-52
[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+branch:master+(topic:implement-default-roles+OR+topic:clean-up-v3-cloud-sample)
[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+branch:master+(topic:implement-default-roles+OR+topic:clean-up-v3-cloud-sample)
[10] http://tinyurl.com/y4vwdsjz