<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>Hey all,<br>
<br>
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.<br>
<br>
<b>Unified Limits</b><b><br>
</b><b><br>
</b>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].<br>
<br>
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.<br>
<br>
<b>Default Roles</b><b><br>
</b><br>
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.<br>
<br>
<b>Capability Lists</b><b><br>
</b><br>
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].<br>
<br>
<b>MFA Receipts</b><b><br>
</b><br>
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.<br>
<br>
<br>
Does anyone have objections to any of these proposals? If not, I
can start bumping various specs to reflect the status described
here.<br>
<br>
<br>
[0]
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2018-July/132202.html">http://lists.openstack.org/pipermail/openstack-dev/2018-July/132202.html</a><br>
</tt><tt><tt>[1]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/strict-two-level-model">https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/strict-two-level-model</a><br>
</tt>[2]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504">https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504</a><br>
[3]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds">https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds</a><br>
[4]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/mfa-auth-receipt">https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/mfa-auth-receipt</a><br>
[5]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1778945">https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1778945</a><br>
<br>
</tt>
</body>
</html>