settingsLogin | Registersettings

[openstack-dev] [Keystone] PTL Candidacy

0 votes

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[1]. 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 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”.

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.

Cheers,

Morgan Fainberg

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046571.html


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Apr 2, 2015 in openstack-dev by Morgan_Fainberg (17,320 points)   2 6 9

4 Responses

0 votes

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[1]. 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
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”.

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.

Cheers,

Morgan Fainberg

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046571.html


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Please vote for Morgan.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 2, 2015 by Adam_Young (19,940 points)   2 7 12
0 votes

On 2015-04-02 19:32:52 -0400 (-0400), Adam Young wrote:
Please vote for Morgan.

Please refrain from distributing campaign literature, placing
political advertising or soliciting votes within 25 meters of the
polling place. ;)
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 2, 2015 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/02/2015 06:50 PM, Jeremy Stanley wrote:

Please vote for Morgan.
Please refrain from distributing campaign literature, placing
political advertising or soliciting votes within 25 meters of the
polling place. ;)

Or quoting the entirety of said campaign literature and adding one
line at the bottom.


iQIcBAEBCgAGBQJVHrS/AAoJEKMgtcocwZqLQ6YP/0Q4miGpeztdQQ48vGdSBsGp
VKEZ3jVaaxp0oxj3gE9HTu4gQHbsQtF5idgElq7QJCt4RiHoaQWF7C62V8bdx04m
y22THw28IuWmY2fyqx6hPx/pHzWZbF0wn3Tj8Qrg+/TT30kBdB4PnDuaceZ9yH/N
A946rHZxW//tVCHTCai5/phXbVuoEIZHY8wNYO9eP/lGrMX0sTmhdIerHwW63tjc
JhVFd2DshduhX4BrNpwdds2jPzWyV7RDgzvxxvOBGBkAjqeUv/95SNJqd8IZLCWh
I5xZ8c3TrSUtqJwndNQ/3w1fTfXPyALQwC+wazAIfnCQ39VM6uxZ/0hhdDMEN5lk
yUFEFf/i6eKpy/cmaEKZC7ZjC2KoKn+/TJiqoVxxYb7/zo6ertDKbaSx3+foGpCX
tJGdngmzJZUUs+uDxsimiOQOuvwoFw1HC+GSdn1cP9CmKN6HyLObKVh/+f/lxpSK
0YyHS6fjdMzkTWcwaCtSx0v6cEA+SbvrtuK4fBVL2YUq0a9TASv+wLFVR1NSDRtv
WrKZz6qZ33PX1DRKHBXaLTQ116eVCh2J1SkbL3ztU6gyJHfqCGm6RkTmYsDFijAt
RK2QOrAm7E9iN05RpiHQbkNa+vT9kJT3nl0dNniBptI2msw8QI4BTQnej/wUbG8O
DOIeMLrLNgDd51CCGjUN
=fsNb
-----END PGP SIGNATURE-----


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 3, 2015 by Ed_Leafe (11,720 points)   1 3 7
0 votes

confirmed

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[1]. 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 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”.

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.

Cheers,

Morgan Fainberg

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046571.html


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Apr 3, 2015 by Tristan_Cacqueray (4,240 points)   3 7
...