Open Stack

The keystone team didn't formally meet at the IRL PTG in Shanghai, but we had
virtual meetings before and after the event to discuss the upcoming cycle.
Below is a summary of what we discussed, more detailed notes were kept in the
main etherpad[1] and sub-pads linked from there.

[1] https://etherpad.openstack.org/p/keystone-shanghai-ptg

Cycle Retrospective
-------------------

https://etherpad.openstack.org/p/keystone-train-retrospective

We started the pre-PTG with our usual end-of-cycle retrospective. One outcome
of this was reevaluating the effectiveness of structured weekly office hours:
we weren't having them frequently because often no one proposed a topic for the
meeting, so we decided to replace the weekly-but-only-sometimes face-to-face
meetings with once per month bug squash meetings. We're also going to
experiment with having a weekly rotation of team members who will act as the
point person for helping triage incoming bugs and responding to users with
support questions, in an effort to create some structure to spread the load of
ensuring users have a positive encounter with the team.

Although we tried to have milestone-ly checkpoints on feature work, that did
not seem to be enough to keep up momentum throughout the cycle on important
features, so we'll try to have more frequent checkpoints, more precise
deadlines, and better decomposition of tasks.

Policy
------

https://etherpad.openstack.org/p/PVG-keystone-forum-policy

The purpose of the policy discussion was mainly to prepare for the forum
session happening the following week, so most of the result is captured by the
forum recap[2]. This was the discussion during which the idea of forming a
pop-up team to work through an initial set of projects, rather than creating a
community goal and attempting to get all projects done in one cycle, was
proposed. We had also discussed creating some kind of "policy-ready" tool to
help operators figure out which projects had completed their migration, but
this seemed only marginally more useful than simply keeping a manually updated
list. (We discussed other ideas for operator tooling at the forum.)

[2] http://www.gazlene.net/shanghai-forum-ptg.html

Limits
------

https://etherpad.openstack.org/p/keystone-ussuri-ptg-unified-limits

We didn't have any design discussion on Unified Limits, since nothing much has
changed since it was discussed at the last PTG. The only issue is that no one
has been working on it in the last cycle, so the next steps were simply to
followup with stakeholders and PoC authors, reassess the priority of the work,
and reinstigate the work (this is now in progress).

SCIM Extension
--------------

We discussed a proposal to add the SCIM protocol[3 as an API extension. The
desire is to be able to sync user state between the keystone SQL database
(including shadow users) and an external identity provider. The main rationale
is to be able to sync the state of the users in an external IdP with the state
of the cloud resources they own, so that, for example, decommissioned users
would not have orphaned cloud resources. However, resources are actually owned
by keystone projects, not users, and there is a many-to-many relationship
between users and projects, so there is no direct link between the state of a
user in the keystone database and the state of a resource they touched.
Moreover, although keystone has a v3-ext section in its API reference[4], we
don't effectively support API extensions because we don't have a discovery
mechanism for them, so for the sake of interoperability we discourage adding
config-enabled API extensions. We suggested that this feature could instead
potentially be implemented as a proxy service in front of keystone, and if such
an implementation turned out to be infeasible, we could revisit adding this to
keystone at a later time.

[3] https://tools.ietf.org/html/rfc7644
[4] https://docs.openstack.org/api-ref/identity/v3-ext/

Cycle Planning
--------------

https://tree.taiga.io/project/keystone-ussuri-roadmap/kanban

This cycle will be lighter in keystone-specific feature work, as much of our
focus will be on cross-project goals. The only new spec to be proposed for
Ussuri will be the Alembic migration[5] which has been in the backlog for a
while. We'll also continue work on unfinished specs from Train[6][7]. We're also
accounting for time needed to work on the community goals[8], as well as
improving our documentation and improving the CLI.

[5] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/alembic.html
[6] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/expiring-group-memberships.html
[7] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/support-federated-attr.html
[8] https://governance.openstack.org/tc/goals/selected/ussuri/index.html