<div dir="ltr">
<p class="MsoNormal">Hello Everyone!</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I came to the table last cycle with a general goal of
driving towards stability and improvement on user experience[1]. For the most
part the Keystone team has managed to improve on a number of the big
outstanding issues:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">* Token Persistence issues (table bloat, etc), solved with
non-persistent (Fernet) tokens.</p>
<p class="MsoNormal" style="margin-left:0.25in"> </p>
<p class="MsoNormal">* Improvements on the Federated identity use-cases.</p>
<p class="MsoNormal" style="margin-left:0.25in"> </p>
<p class="MsoNormal">* Hierarchical Multi-Tenancy (initial implementation)</p>
<p class="MsoNormal" style="margin-left:0.25in"> </p>
<p class="MsoNormal">* Significant progress on Keystone V3-only deployment models
(a lot of work in the Keystone Client and Keystone Middleware)</p>
<p class="MsoNormal" style="margin-left:0.25in"> </p>
<p class="MsoNormal">* A good deal of technical debt paydown / cleanup</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">New Feature Work:</p>
<p class="MsoNormal">-------------------------</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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”.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Non-Feature Work:</p>
<p class="MsoNormal">-------------------------</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Some Concluding Thoughts:</p>
<p class="MsoNormal">------------------------------------</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I’ll reiterate my conclusion from the last time I ran, as it
still absolutely sums up my feelings:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Cheers,</p>
<p class="MsoNormal">Morgan Fainberg</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-September/046571.html">http://lists.openstack.org/pipermail/openstack-dev/2014-September/046571.html</a></p>
</div>