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