# 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 

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
[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].

[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

## 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 
Bug #1777892 (keystone:Medium) opened by Lance Bragstad 
Bug #1777893 (keystone:Medium) opened by Lance Bragstad 
Bug #1778023 (keystone:Undecided) opened by kirandevraaj 
Bug #1778109 (keystone:Undecided) opened by Jeremy Freudberg 

Bugs closed (2) 
Bug #1758460 (keystone:Low) https://bugs.launchpad.net/keystone/+bug/1758460 
Bug #1774654 (keystone:Undecided) 

Bugs fixed (2) 
Bug #1754184 (keystone:Medium) fixed by wangxiyuan 
Bug #1774229 (keystone:Medium) fixed by Lance Bragstad 

## Milestone Outlook


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: 
Dashboard generated using gerrit-dash-creator and 

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to