[openstack-dev] [keystone] Feature Status and Exceptions
lbragstad at gmail.com
Fri Jul 13 20:59:06 UTC 2018
On 07/13/2018 02:37 PM, Harry Rybacki wrote:
> On Fri, Jul 13, 2018 at 3:20 PM Lance Bragstad <lbragstad at gmail.com> wrote:
>> Hey all,
>> As noted in the weekly report , 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 .
>> 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 . 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 .
>> 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 .
>> 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 . 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 . 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.
>>  http://lists.openstack.org/pipermail/openstack-dev/2018-July/132202.html
>>  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+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504
>>  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/mfa-auth-receipt
>>  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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-dev