On Fri, Jul 13, 2018 at 3:20 PM Lance Bragstad <lbrags...@gmail.com> 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. > +1 to this approach.
> 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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
