<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>