Developing Keystone Drivers¶

In/Out of Tree¶

It’s best to start developing your custom driver outside of the Keystone development process. This means developing it in your own public or private git repository and not worrying about getting it upstream (for now).

This is better for you because it gives you more freedom and you are not bound to the strict OpenStack development rules or schedule. You can iterate faster and take whatever shortcuts you need to get your product out of the door.

This is also good for Keystone because it will limit the amount of drivers that must be maintained by the team. If the team had to maintain a driver for each NoSQL DB that deployers want to use in production there would be less time to make Keystone itself better. Not to mention that the team would have to start gaining expertise in potentially dozens of new technologies.

As you’ll see below there is no penalty for open sourcing your driver, on GitHub for example, or even keeping your implementation private. We use Setuptools entry points to load your driver from anywhere in the Python path.

How To Make a Driver¶

The TLDR; steps (and too long didn’t write yet):

1. Determine which subsystem you would like write a driver for

2. Subclass the most current version of the driver interface

3. Implement each of the abstract methods for that driver

   1. We are currently not documenting the exact input/outputs of the driver methods. The best approach right now is to use an existing driver as an example of what data your driver will receive and what data your driver will be required to return.

   2. There is a plan in place to document these APIs in more detail.

4. Register your new driver as an entry point

5. Configure your new driver in keystone.conf

6. Sit back and enjoy!

Driver Interface Changes¶

We no longer support driver versioning. Thus, if a driver interface changes, you will need to upgrade your custom driver to meet the new driver contract.