Re: [openstack-dev] [Keystone] PTL Candidacy: Adam Young
I'm not sure if I should reply to you or not since I am not developer of this project but another. But I would like to let you know what I am really really thinking how the Keystone should work is: Just HUB I know that this description would be confusing you and developers subscribing this list. Anyhow here is my thoughts. >1. Removing the bearer aspects of tokens Yes, that is what I am thinking of. >2. Better delegation mechanisms to scale the management of OpenStack. Yes, that is what I am thinking of. >3. Improving stability, scale, and performance. Plus security and isolation, if it would work as security hub for the OpenStack. >4. Simplify integration with external identity sources Yes, that is what I am thinking of. Shinobu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] PTL Candidacy
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature
Re: [openstack-dev] [Keystone] PTL Candidacy
-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. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] PTL Candidacy
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-requ...@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:
Re: [openstack-dev] [Keystone] PTL Candidacy
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] PTL Candidacy
confirmed On 09/19/2014 05:14 PM, Morgan Fainberg wrote: Hello Everyone! After contributing consistently to OpenStack since the Grizzly cycle and more specifically to Keystone since Havana, I’d like to put my name into the hat for the Keystone PTL role during the Kilo release cycle. I’ve been a core developer on Keystone since the latter part of the Havana cycle and have largely been focused on the improvement of performance and consistency of the Keystone APIs, helping new developers contribute to OpenStack, and working cross-team to ensure the other projects have the support they need from Keystone to succeed. My primary interests for project the continued drive of stability and improvement on the user experience. This direction involves finding a balance between the desires for new features and improving upon what we’ve already developed. In the last two cycles I’ve seen an incredible move towards making Keystone a more full featured Authentication, Authorization, and Audit program. This in no small part is credited to the incredible team of contributors (whether they are operations-focused and providing feedback, developers working on cleaner enterprise integration such as federated identity, or anything in between). For the Kilo cycle I would like to see Keystone development focus on improving the experience for everyone interacting with the service. This continues to place a very heavy focus on improvement of the client and middleware (keystoneclient, keystonemiddleware, and the integration of the other OpenStack client libraries/cli tools with keystoneclient to use Sessions, pluggable auth, etc). This focus on client work will also be aimed at finishing the work needed to get all OpenStack projects fully utilizing and working with the Keystone V3 API. In terms of the Keystone service itself, I would like to see a balance of somewhere about 25% new development (wholly new features) that are landed early in the release cycle and 75% of development efforts on improving the features we have as of the Juno release. This latter 75% would include continued enhancements to systems such as federation, expanded auth mechanisms, a heavy focus on overall performance (including a continued hard look at token performance), a focus improvement on the tests to ensure we test and gate on real-world deployment scenarios, and smoothing out the rough edges when interacting with Keystone’s APIs. In short, I think we’ve been largely heading the right direction with Keystone, but there are still a lot of things we can do to improve and in the process not only pay down some technical debt we may have accrued but make Keystone significantly better for our developers, deployers, and users. Last of all, I want to say that 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 Kilo release cycle and beyond not just for Keystone but all of OpenStack. Cheers, Morgan Fainberg — Morgan Fainberg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Keystone PTL Candidacy
confirmed On 04/02/2014 02:48 PM, Dolph Mathews wrote: Hello, everyone! I'd like to keep my name in the hat as PTL for Keystone during the Juno release cycle. As I'm not looking to shake things up for Juno, I'm going to direct you to my Icehouse PTL candidacy email [1], and promise that I will continue to deliver on that philosophy in Juno. Specifically, it's worth reiterating that my primary focus is in ... supporting our outstanding community of contributors in any way that I can so that they can be as productive as possible. Never mind the PTL, Keystone's success would not be possible without the community behind it. I actually view the client-side pieces to be the most important parts of keystone (and keystoneclient.middleware.auth_token, in particular) due to the more immediate impact on our stakeholders. In terms of Juno, I'm especially looking forward to landing support for ephemeral, signed tokens backed by revocation events on the client-side, along with increasing adoption for keystoneclient.session (and therefore the v3 API) across OpenStack. To all of our contributors during Icehouse: THANK YOU! -Dolph [1] http://lists.openstack.org/pipermail/openstack-dev/2013-September/015387.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
