Just after the OpenStack
Essex 3 milestone, Ziad Sawalha of Rackspace announced a major shift in the Keystone code base. I applaud the clarity of Ziad’s email but want to restate my understanding of the changes here rather than simply parrot him.

These changes improve Keystone and OpenStack in several ways.

The Keystone team is keeping the current APIs while swapping their implementation. They recommend switching back to an implementation based on the Rackspace Cloud Builder’s Keystone Light code base. I say switching back because my team at Dell has some experience with the Keystone Light (KSL) code. KSL was used with our first Diablo release work while legacy Keystone (Diablo Keystone?) was being readied for release. Upon reflection, the confusion around Keystone readiness for Diablo may have been an indicator to some disconnects that ultimately contributed to last week’s decision.

This is not an 11^th hour rewrite. Keystone Light (now Essex Keystone?) offers

• An existing code base that has been proven in real deployments
• Stronger identity pluggability, better EC2 compatibility and higher production readiness
• An existing testing framework and proven extensibility and flexibility
• Plus, the team has committed to ensure a simple migration path

Beyond the code and Keystone, making a change like this takes confidence and guts.

This change is not all sunshine and rainbows. Making a major change midway through the release cycle introduces schedule and delivery risk. Even though not fully graduated to core project status, Keystone is already an essential component in OpenStack. People will certainly raise valid questions about production readiness and code churn within the project. Changes like these are the reality for any major project and doubly so for platforms.

The very fact that this change is visible and discussed by the OpenStack community shows our strength.

Acknowledging and quickly fixing a weakness in the OpenStack code base is exactly the type of behavior that the community needs to be successful and converge towards a great platform. The fact that maintaining the API is a priority shows that OpenStack is moving in the direction of more API based standards. While the Keystone change is not a recommendation for dual implementations (the Diablo Keystone fork will likely die out), it should help set the stage for how the community will handle competing implementations. If nothing else, it is a strong argument for maintaining API tests and compliance.

The Keystone change is a forward looking one. Our Crowbar team will investigate how we will incorporate it.  As part of OpenStack, the new Keystone code will (re)surface for the Essex deployment and that code will be part of the Dell OpenStack-Powered Cloud.  This work, like the previous, will be done in the open as part of the OpenStack barclamps that we maintain on the Crowbar github.