It’s been an exciting development cycle (Kilo) and it is now time to start
looking forward at Liberty and what that will hold. With that said, I’d
like to ask for the community’s support to continue as the Keystone PTL for
the Liberty release cycle.
I came to the table last cycle with a general goal of driving towards
stability and improvement on user experience. For the most part the
Keystone team has managed to improve on a number of the big outstanding
Token Persistence issues (table bloat, etc), solved with non-persistent
Improvements on the Federated identity use-cases.
Hierarchical Multi-Tenancy (initial implementation)
Significant progress on Keystone V3-only deployment models (a lot of work
in the Keystone Client and Keystone Middleware)
A good deal of technical debt paydown / cleanup
This cycle I come back to say that I don’t want to shake things up too
much. I think we have a successful team of developers, reviewers,
bug-triagers, and operators collaborating to make Keystone a solid part of
the OpenStack Ecosystem. I remain committed to enabling the contributors
(of all walks) to be part of our community and achieve success.
For the Liberty cycle I would like to see a continued focus on performance,
user experience, deployer experience, and stability. What does this really
mean for everyone contributing to Keystone? It means there are two clear
sides for the Liberty cycle.
New Feature Work:
I want to see the development community pick a solid 5 or so “new” features
to land in Liberty and really hit those out of the park (focused
development from the very beginning of the cycle). Generally speaking, it
looks that the new feature list is lining up around providing support /
significantly better experience for the other project(s) under the
OpenStack tent. In short, I see Keystone new development being less about
the “interesting thing Keystone can do” and more about “the great things
Keystone can do for the other projects”.
We have a lot of drivers/plugins, backends, all with their own rapidly
moving interfaces that make it hard to know what to expect in the next
release. It is time we sit down and commit to the interfaces for the
backends, treat them as stable (just like the REST interface). A stable ABI
for the Keystone backends/plugins goes a long way towards enabling our
community to develop a rich set of backends/plugins for Identity,
Assignment, Roles, Policy, etc. This is a further embracing of the “Big
Tent” conversation; for example we can allow for constructive competition
in how Keystone retrieves Identity from an Identity store (such as LDAP,
AD, or SQL). Not all of the solutions need to be in the Keystone tree
itself, but a developer can be assured that their driver isn’t going to
need radical alterations between Liberty and the next release with this
commitment to stable ABIs.
Beyond the stable interface discussion, the other top “non-feature”
priorities are having a fully realized functional test suite (that can be
run against an arbitrary deployment of Keystone, with whichever
backend/configuration is desired), a serious look at performance profiling
and what we can do to solve the next level of scaling issues, the ability
to deploy OpenStack without Keystone V2 enabled, and finally looking at the
REST API itself so that we can identify how we can improve the end-user’s
experience (the user who consumes the API itself) especially when it comes
to interacting with deployments with different backend configurations.
Some Concluding Thoughts:
I’ll reiterate my conclusion from the last time I ran, as it still
absolutely sums up my feelings:
Above and beyond everything else, as PTL, I am looking to support the
outstanding community of developers so that we can continue Keystone’s
success. Without the dedication and hard work of everyone who has
contributed to Keystone we would not be where we are today. I am extremely
pleased with how far we’ve come and look forward to seeing the continued
success as we move into the Liberty release cycle and beyond not just for
Keystone but all of OpenStack.
OpenStack Development Mailing List (not for usage questions)