Re: [openstack-dev] [keystone] Keystone Team Update - Week of 18 June 2018
Also: keystoneauth1 3.9.0 was released. Its new feature is the ability to set raise_exc on the Adapter object so you don't have to do it per request. Here's a patch that makes use of the feature: https://review.openstack.org/#/c/577437/ -efried On 06/22/2018 06:53 AM, Colleen Murphy wrote: > # Keystone Team Update - Week of 18 June 2018 > > ## News > > ### Default Roles Fallout > > Our change to automatically create the 'reader' and 'member' roles during > bootstrap[1] caused some problems in the CI of other projects[2]. One problem > was that projects were manually creating a 'Member' role, and with the > database backend being case-insensitve, there would be a conflict with the > 'member' role that keystone is now creating. The immediate fix is to ensure > the clients in CI are checking for the 'member' role rather than the 'Member' > role before trying to create either role, but in the longer term, clients > would benefit from decoupling the API case sensitivity from the configuration > of the database backend[3]. > > Another problem was a bug related to implied roles in trusts[4]. If a role > implies another, but a trust is created with both roles explicitly, the token > will contain duplicate role names, which breaks the usage of trusts and hit > Sahara. This issue would have existed before, but was only discovered now > that we have implied roles by default. > > [1] https://review.openstack.org/572243 > [2] > http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-24 > [3] > http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-175 > [4] https://bugs.launchpad.net/keystone/+bug/1778109 > > ### Limits Schema Restructuring > > Morgan discovered some problems with the database schemas[5] for registered > limits and project limits and proposed that we can improve performance and > reduce data duplication by doing some restructuring and adding some indexes. > The migration path to the new schema is tricky[6] and we're still trying to > come up with a strategy that avoids triggers[7]. > > [5] > http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-184 > [6] > http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:04:05 > [7] https://etherpad.openstack.org/p/keystone-unified-limit-migration-notepad > > ### No-nitpicking Culture > > Following the community discussion on fostering a healthier culture by > avoiding needlessly nitpicking changes[8], the keystone team had a thoughtful > discussion on what constitutes nitpicking and how we should be voting on > changes[9]. Context is always important, and considering who the author is, > how significant the imperfection is, and how much effort it will take the > author to correct it should to be considered when deciding whether to ask > them to change something about their patch versus proposing yor own fix in a > folllowup. I've always been proud of keystone's no-nitpicking culture and > it's encouraging to see continuous introspection. > > [8] https://governance.openstack.org/tc/reference/principles.html > [9] > http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:18:01 > > ## Recently Merged Changes > > Search query: https://bit.ly/2IACk3F > > We merged 16 changes this week, including client support for limits and a > major bugfix for implied roles. > > ## Changes that need Attention > > Search query: https://bit.ly/2wv7QLK > > There are 57 changes that are passing CI, not in merge conflict, have no > negative reviews and aren't proposed by bots, so their authors are waiting > for any feedback. > > ## Bugs > > This week we opened 5 new bugs and closed 4. > > Bugs opened (5) > Bug #1777671 (keystone:Medium) opened by Morgan Fainberg > https://bugs.launchpad.net/keystone/+bug/1777671 > Bug #1777892 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1777892 > Bug #1777893 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1777893 > Bug #1778023 (keystone:Undecided) opened by kirandevraaj > https://bugs.launchpad.net/keystone/+bug/1778023 > Bug #1778109 (keystone:Undecided) opened by Jeremy Freudberg > https://bugs.launchpad.net/keystone/+bug/1778109 > > Bugs closed (2) > Bug #1758460 (keystone:Low) https://bugs.launchpad.net/keystone/+bug/1758460 > Bug #1774654 (keystone:Undecided) > https://bugs.launchpad.net/keystone/+bug/1774654 > > Bugs fixed (2) > Bug #1754184 (keystone:Medium) fixed by wangxiyuan > https://bugs.launchpad.net/keystone/+bug/1754184 > Bug #1774229 (keystone:Medium) fixed by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1774229 > > ## Milestone Outlook > > https://releases.openstack.org/rocky/schedule.html > > This week is our feature proposal freeze
[openstack-dev] [keystone] Keystone Team Update - Week of 18 June 2018
# Keystone Team Update - Week of 18 June 2018 ## News ### Default Roles Fallout Our change to automatically create the 'reader' and 'member' roles during bootstrap[1] caused some problems in the CI of other projects[2]. One problem was that projects were manually creating a 'Member' role, and with the database backend being case-insensitve, there would be a conflict with the 'member' role that keystone is now creating. The immediate fix is to ensure the clients in CI are checking for the 'member' role rather than the 'Member' role before trying to create either role, but in the longer term, clients would benefit from decoupling the API case sensitivity from the configuration of the database backend[3]. Another problem was a bug related to implied roles in trusts[4]. If a role implies another, but a trust is created with both roles explicitly, the token will contain duplicate role names, which breaks the usage of trusts and hit Sahara. This issue would have existed before, but was only discovered now that we have implied roles by default. [1] https://review.openstack.org/572243 [2] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-24 [3] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-175 [4] https://bugs.launchpad.net/keystone/+bug/1778109 ### Limits Schema Restructuring Morgan discovered some problems with the database schemas[5] for registered limits and project limits and proposed that we can improve performance and reduce data duplication by doing some restructuring and adding some indexes. The migration path to the new schema is tricky[6] and we're still trying to come up with a strategy that avoids triggers[7]. [5] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-184 [6] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:04:05 [7] https://etherpad.openstack.org/p/keystone-unified-limit-migration-notepad ### No-nitpicking Culture Following the community discussion on fostering a healthier culture by avoiding needlessly nitpicking changes[8], the keystone team had a thoughtful discussion on what constitutes nitpicking and how we should be voting on changes[9]. Context is always important, and considering who the author is, how significant the imperfection is, and how much effort it will take the author to correct it should to be considered when deciding whether to ask them to change something about their patch versus proposing yor own fix in a folllowup. I've always been proud of keystone's no-nitpicking culture and it's encouraging to see continuous introspection. [8] https://governance.openstack.org/tc/reference/principles.html [9] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:18:01 ## Recently Merged Changes Search query: https://bit.ly/2IACk3F We merged 16 changes this week, including client support for limits and a major bugfix for implied roles. ## Changes that need Attention Search query: https://bit.ly/2wv7QLK There are 57 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots, so their authors are waiting for any feedback. ## Bugs This week we opened 5 new bugs and closed 4. Bugs opened (5) Bug #1777671 (keystone:Medium) opened by Morgan Fainberg https://bugs.launchpad.net/keystone/+bug/1777671 Bug #1777892 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1777892 Bug #1777893 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1777893 Bug #1778023 (keystone:Undecided) opened by kirandevraaj https://bugs.launchpad.net/keystone/+bug/1778023 Bug #1778109 (keystone:Undecided) opened by Jeremy Freudberg https://bugs.launchpad.net/keystone/+bug/1778109 Bugs closed (2) Bug #1758460 (keystone:Low) https://bugs.launchpad.net/keystone/+bug/1758460 Bug #1774654 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1774654 Bugs fixed (2) Bug #1754184 (keystone:Medium) fixed by wangxiyuan https://bugs.launchpad.net/keystone/+bug/1754184 Bug #1774229 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1774229 ## Milestone Outlook https://releases.openstack.org/rocky/schedule.html This week is our feature proposal freeze deadline. All our major efforts seem to have at least one initial patch proposed for them. The keystone feature freeze is only 3 weeks away. The final release for non-client libraries is the week after that[10], so we need to ensure that all the work needed especially for keystonemiddleware is completed by them. [10] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131732.html ## Help with this newsletter Help contribute to this newsletter by editing the etherpad:
