<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/02/2015 04:31 PM, Morgan Fainberg
wrote:<br>
</div>
<blockquote
cite="mid:CAGnj6avBXC=A9+ULbpka2CKTFMncVdDsJTJZRPAOpO2zeaQGmw@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
Please vote for Morgan. <br>
<br>
<br>
<br>
</body>
</html>