Open Stack

Hey all,

As noted in the weekly report [0], today is feature freeze for
keystone-related specifications. I wanted to elaborate on each
specification so that our plan is clear moving forward.

*Unified Limits**
**
*I propose that we issue a feature freeze exception for this work.
Mainly because the changes are relatively isolated and low-risk. The
majority of the feedback on the approach is being held up by an
interface decision, which doesn't impact users, it's certainly more of a
developer preference [1].

That said, I don't think it would be too ambitious to focus reviews on
this next week and iron out the last few bits well before rocky-3.

*Default Roles**
*
The implementation to ensure each of the new defaults is available after
installing keystone is complete. We realized that incorporating those
new roles into keystone's default policies would be a lot easier after
the flask work lands [2]. Instead of doing a bunch of work to
incorporate those default and then re-doing it to accommodate flask, I
think we have a safe checkpoint where we are right now. We can use free
cycles during the RC period to queue up those implementation, mark them
with a -2, and hit the ground running in Stein. This approach feels like
the safest compromise between risk and reward.

*Capability Lists**
*
The capability lists involves a lot of work, not just within keystone,
but also keystonemiddleware, which will freeze next week. I think it's
reasonable to say that this will be something that has to be pushed to
Stein [3].

*MFA Receipts**
*
Much of the code used in the existing approach uses a lot of the same
patterns from the token provider API within keystone [4]. Since the UUID
and SQL parts of the token provider API have been removed, we're also in
the middle of cleaning up a ton of technical debt in that area [5].
Adrian seems OK giving us the opportunity to finish cleaning things up
before reworking his proposal for authentication receipts. IMO, this
seems totally reasonable since it will help us ensure the new code for
authentication receipts doesn't have the bad patterns that have plagued
us with the token provider API.


Does anyone have objections to any of these proposals? If not, I can
start bumping various specs to reflect the status described here.


[0] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132202.html
[1]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/strict-two-level-model
[2]
https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504
[3]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds
[4]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/mfa-auth-receipt
[5]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1778945

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180713/be46718e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180713/be46718e/attachment.sig>