On 07/13/2018 02:37 PM, Harry Rybacki wrote: > 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.
I've proposed a couple updates to the specification, trying to clarify exactly what was implemented in the release [0]. [0] https://review.openstack.org/#/c/582673/ > >> 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
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
