[openstack-dev] [keystone] Feature Status and Exceptions

Colleen Murphy colleen at gazlene.net
Mon Jul 16 06:39:56 UTC 2018

On Fri, Jul 13, 2018, at 9:19 PM, Lance Bragstad wrote:
> 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.

All sounds good to me, thanks for writing this up.

> [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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

More information about the OpenStack-dev mailing list