osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[keystone] Keystone Train Midcycle Report


This week the keystone team conducted a two-day virtual midcycle. Thanks to
everyone who participated and contributed to making this a successful and
productive meeting! This email will be a short summary of the key takeaways
from the last two days. The full agenda and meeting notes can be found on this
etherpad:

https://etherpad.openstack.org/p/keystone-train-midcycle-topics

# Caching Guide

We've long been proposing to document best practices for configuring caching
for keystone. We began the meeting with a discussion about what exactly should
be contained in such a guide, starting with anecdotes from the team about our
own operational experience with configuring memcached for keystone. We quickly
realized the guide needed at least two parts, one for keystone itself and one
for keystonemiddleware. We also made two technical observations, first that the
default value for the memcache_socket_timeout option in oslo.cache could be
reduced[1] and second that the memcache_socket_timeout option exposed in
keystone is not actually used by keystone and needs to be removed[2]. We talked
about security strategies for memcached: oslo.cache exposes encryption
capabilities which is required for organizations that consider the data stored
in memcached to be "at rest", but it also hurts performance. An alternative
strategy that could be recommended in the guide is to set up TLS tunneling to
secure in-flight data without impeding fetching performance.

The initial caching guide update was proposed here[3]. This guide will be a
living document and will continue to grow as we gather real-life data from
operators. After this initial update, we'll start taking steps to ensure that
keystone requires caching be set up in order to operate.

[1] https://review.opendev.org/672063
[2] https://bugs.launchpad.net/keystone/+bug/1837407
[3] https://review.opendev.org/672120

# Community Goals

We then had a short status update session on the various community goals we
need to meet. The mutable config goal from a few cycles ago is not yet complete
but has an implementation proposed[4] which needs more eyes and testing. The
PDF generation goal implementation is underway[5] but there are some issues
already being tracked by the community[6]. We will need to work to ensure the
issues we're seeing are noted and addressed. The last of the Python3 Train job
changes for keystone repos were merged, so I think we've completed our end of
that goal. We also already have a patch proposed to add the ipv6-only job[7]
which is just waiting on the base job to merge in tempest.

[4] https://review.opendev.org/585417
[5] https://review.opendev.org/669982
[6] https://etherpad.openstack.org/p/pdf-goal-train-common-problems
[7] https://review.opendev.org/671903

# Milestone 2 Train Retrospective

We closed out the first day with a mid-cycle retrospective[8]. Some key areas
for improvement from this were:

* Do more video conferencing
  - The real-time face-to-face communication is really effective for getting to
    the heart of discussions and making decisions quickly
  - Since it is looking likely that most of us will not be at the next PTG in
    Shanghai, we can set up a pre- and post- PTG video meeting to plan the
    cycle and catch people up after the IRL PTG
  - Milestone-ly video meetings are working for helping us keep pace and sync
    up
  - We can keep a queue of potential topics and make sure we have a meeting
    when there are enough topics to discuss
  - We'll try using video conferencing for office hours
  - We'll try Jitsi again even though there were some technical issues last
    time since it is OSS and supports recording

* Improve office hours
  - Office hours still don't feel useful and haven't happened regularly, but we
    still think they have potential
  - We'll use the weekly newsletter to commit to the topic the week before,
    which gives the team a better opportunity to prepare for it and can also
    attract interest from people outside the keystone team
  - Use video conferencing as mentioned above

* Improve the weekly newsletter
  - We'll use the weekly newsletter to call out action items from the last
    meeting
  - In addition to providing statistics about the number of open reviews, we'll
    highlight certain reviews that need attention based on various criteria
    such as age, priority with regard to cycle commitments, community goals,
    and specific review requests.
  - We'll announce the following week's office hours topic in the newsletter

[8] https://etherpad.openstack.org/p/keystone-train-midcycle-retrospective

# System Scope and Default Roles

The second day of the midcycle was used to go through our list of open system
scope[9] and default roles[10] bugs and work through what scopes and roles each
API should support. The notes in the etherpad largely capture every decision
fairly well, but a few issues worth highlighting are:

* Implied roles[11]: the regular roles API is currently system-scope only, even
  though it's possible to have domain-specific roles, because for the most part
  for a role to be useful the role's creator must also have the ability to
  configure policy, which domain admins do not. Implied roles still require
  access to policy configuration except in the case where you are only using
  implied roles for aliasing, in which case it may make sense for a domain
  admin to have the ability to create an implied role relationship. We decided
  to start with making the implied roles API system-scope only for now and
  to open a separate bug to discuss how to deal with domain-specific roles and
  implied roles.

* Revocation list[12]: we're currently not enforcing policy on this API at all
  because it can only ever return a 410 Gone or a 403 Forbidden, never a
  success, so we will just deprecate the policy entirely rather than updating
  it to work with system scope or default roles.

We reevaluated the priority on some of the bugs in the list. However, we noted
that while some APIs are more heavily used than others, we can't change
enforce_scope to True until all of them are completed - picking and choosing
the most important ones and letting the others slide is not really an option.

[9] https://bugs.launchpad.net/keystone/+bugs?field.tag=system-scope
[10] https://bugs.launchpad.net/keystone/+bugs?field.tag=default-roles
[11] https://bugs.launchpad.net/keystone/+bug/1805371
[12] https://bugs.launchpad.net/keystone/+bug/1818845

If I've left out any important details, don't hesitate to add them to this
thread.

Thanks again to everyone who was able to join the meeting! Thanks also to Julia
Kreger for her advice on how to hold one of these virtual midcycles, it proved
to be very useful and this first-timer really appreciated it :)

Colleen