Stable Keystone Driver Interfaces¶
Keystone has a number of backend drivers that are purportedly able to be replaced by a developer or deployer with their own implementation (e.g. utilizing mongodb as a store for Identity information). Currently these drivers have had significant interface changes each cycle making it difficult for developers to maintain custom (or subclassed) drivers as each release has caused a significant delta in all of the Keystone Driver Interface definitions.
Problem Description¶
To properly support developers who are implementing drivers for Keystone out of tree, the Keystone Driver Interface need to be stable like the REST API is. This specification is to commit to the interface for each driver and ensure that drivers that are written against Liberty will work with the M-Release of Keystone as well (a minimum of 2-cycle Interface commitment).
Changes to a given driver interface will require compatibility code (to be provided by the developer that is proposing the change) to ensure that the supported window of stability is maintained. This means that when a driver interface change is proposed (via a new version for the specific subsystem), Keystone will need appropriate logic to work with both the new version and any currently supported version.
Proposed Change¶
Each subsystem will have it’s driver ABC Base class looked at for a redesign. The keystone stable driver interface definitions will be versioned and Keystone will ensure that it can load any version of the driver interface.
Alternatives¶
Alternatives include “trying” to ensure we don’t break the driver interface [best effort] or continuing with the current way of allowing interfaces to change between releases. This however, is a sub-optimal experience for deployers and developers.
Security Impact¶
Changes to the driver interfaces to address Security concerns could become more difficult. There should be no direct security impact. Each driver interface definition will need to be reviewed, but this is the same as any change impacting a given driver interface.
Notifications Impact¶
No notification changes should be needed.
Other End User Impact¶
No changes to end users.
Performance Impact¶
No expected performance changes.
Other Deployer Impact¶
Deployers will be able to utilize drivers for more versions of Keystone than before. However, there should be minimal deployer impact.
Developer Impact¶
Developers will need to be aware of how to change the driver interface definitions. This will include needing to develop the compatibility layer if a driver interface needs to be changed so previous versions of the driver can be loaded.
Implementation¶
Assignee(s)¶
Primary assignee:
gyee (Guang Yee)
ajayaa (Ajaya Agrawal)
rushiagr (Rushi Agrawal)
Work Items¶
Evaluate and develop the stable interfaces for the following subsystems:
Catalog
Resource
Identity
Assignment
Assignment.Roles
Credential
Token Persistence
Token Provider
Policy
Federation
OAuth
Endpoint Policy
Convert current drivers to the new driver interface definitions
Create a separate repo or suite of tests that implements a base (just simple) version of the drivers that can be used for validation / loading to ensure compatibility / loading works as expected when/if the interface changes.
Dependencies¶
None
Documentation Impact¶
Documentation on how to update the driver interfaces and what is expected in compatibility will be needed. Clear indication of the driver interface definitions will need to be clearly indicated in our documents.
