[openstack-dev] [Keystone] PTL Candidacy
ayoung at redhat.com
Thu Apr 2 23:32:52 UTC 2015
On 04/02/2015 04:31 PM, Morgan Fainberg wrote:
> Hello Everyone!
> 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 issues:
> * Token Persistence issues (table bloat, etc), solved with
> non-persistent (Fernet) tokens.
> * 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
> 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”.
> Non-Feature Work:
> 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.
> Morgan Fainberg
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Please vote for Morgan.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev