[openstack-dev] [keystone] PTL Candidacy for the Stein cycle
Hey everyone, I'm writing to submit my self-nomination as keystone's PTL for the Stein release. We've made significant progress tackling some of the major goals we set for keystone in Pike. Now that we're getting close to wrapping up some of those initiatives, I'd like to continue advocating for enhanced RBAC and unified limits. I think we can do this specifically by using them in keystone, where applicable, and finalize them in Stein. While a lot of the work we tackled in Rocky was transparent to users, it paved the way for us to make strides in other areas. We focused on refactoring large chunks of code in order to reduce technical debt and traded some hand-built solutions in favor of well-known frameworks. In my opinion, these are major accomplishments that drastically simplified keystone. Because of this, it'll be easier to implement new features we originally slated for this release. We also took time to smooth out usability issues with unified limits and implemented support across clients and libraries. This is going to help services consume keystone's unified limits implementation early next release. Additionally, I'd like to take some time in Stein to focus on the next set of challenges and where we'd like to take keystone in the future. One area that we haven't really had the bandwidth to focus on is federation. From Juno to Ocata there was a consistent development focus on supporting federated deployments, resulting in a steady stream of features or improvements. Conversely, I think having a break from constant development will help us approach it with a fresh perspective. In my opinion, federation improvements are a timely thing to work on given the use-cases that have been cropping up in recent summits and PTGs. Ideally, I think it would great to come up with an actionable plan for making federation easier to use and a first-class tested citizen of keystone. Finally, I'll continue to place utmost importance on assisting other services in how they consume and leverage the work we do. Thanks for taking a moment to read what I have to say and I look forward to catching up in Denver. Lance signature.asc Description: OpenPGP digital 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
[openstack-dev] [keystone] PTL candidacy
Hello everyone! I have been involved in OpenStack since late 2013 and now it is time to put my name forward as a candidate for keystone PTL during the Pike development cycle. See my openstack/election change in [1]. As your PTL, I would like to see our team's focuses classified into three categories, as enumerated and detailed below: 1. Community: keeping keystone a great place to contribute As a team, we need to ensure our project is always a welcoming place to new contributors. I would like to encourage community members who have more experience in the project to take leadership roles, such as mentoring GSoC and Outreachy programs. Regarding those programs, it would be great to elaborate a list of projects we consider to be interesting and that can be scoped in an internship. In addition, I would like to keep identifying and rewarding community members who have been doing an outstanding job, as this helps on keeping them motivated and knowing how great and important they are to our community. 2. Features and testing: establishing a consistent roadmap In terms of features, I would like to see our team keeping hardening some features that have landed in Ocata, such as PCI-DSS and federated auto-provisioning. Some others would be targeted to Pike, including continuing to work in the solution for solving the issue with long-running operations and token expiry, and improvements in the policy mechanisms. In terms of testing, the team has been doing a great job. Some functional tests have been added in Ocata. I would like to see our team to continue improving our tests in order to make sure we continue to deliver high quality code to our users. 3. Docs: revisiting and ensuring consistency and completeness I would like to keep revisiting our developer docs in order to make sure new contributors have a smoothly experience when onboarding. Furthermore, I would like to note that there is no point in having a code that behaviors correctly if we do not teach our users how to use our service. With that said, in order to keep improving usability, I would like to see the team making sure the docs are accurate and complete for our API consumers and deployers. There are a few ideas on how to improve docs out there, such as api-guide docs, which main goal is to conceptually explain the service. -- I will hapilly discuss those goals with the team during our first PTG in Atlanta. I am looking forward to seeing you there! Thank you, Samuel de Medeiros Queiroz - samueldmq [1] https://review.openstack.org/#/c/424239/ __ 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
[openstack-dev] [keystone] PTL candidacy
Hello, everyone! First of all, I would like to thanks all the previous Keystone PTLs, core reviewers and contributors who have made OpenStack and Keystone what they are today. It is been a pleasure for me to work in this team and learn with you all. I would be honored to be your PTL during the next development cycle. That said, I would like to put my name forward as a candidate for PTL during the Ocata release [1]. I have been involved in OpenStack since the Icehouse release and I have been a core reviewer on Keystone since the Mitaka release. During the Newton cycle, I also served as the Keystone cross-project liaison and participated as a mentor for the Outreachy program. My main focuses have been helping new developers to contribute to the project and improving documentation. I have been doing my best to review elected priorities, helping the team to deliver what was scoped to the release cycle. Given that the Ocata development window is shorter, my main goal for Ocata is to focus on the stability and usability of the project. My primary subgoals include a) tackling the issue with long-running operations and token expiry, b) keeping up the good work on improving api-ref docs and creating the api-guide docs, and c) ensuring Keystone is a friendly place for new contributors to get started. Other subgoals that are nice to have but still important are d) broadening our tests environments to include functional tests for LDAP backends, auditing, and federated identity workflows, and e) making the default RBAC authorization more granular. Thank you, Samuel de Medeiros Queiroz [1] https://review.openstack.org/#/c/369002/ __ 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
[openstack-dev] [keystone] PTL candidacy
Hey everyone, I'd like to continue to serve as the Keystone PTL for the Newton release. I found serving as PTL for the Mitaka release to be an extremely rewarding experience where I learned a lot about myself and the project. I’d like to continue what I’ve learned and serve as PTL again. I am also fortunate enough to work for an employer where I can dedicate 100% of my time to upstream contributions. With all that said, I believe I'm even more prepared to go at it again! We met a lot of goals from my original mission statement [0] and snuck in a few other features that were not listed, you can read the Mitaka recap here [1]. We completed 16 blueprints; ended Mitaka with a very low bug count (down from over 300 to 107); and nominated two new core members. I'm very proud of the work the entire team did during the Mitaka development cycle. I know it's been said many times before but this is a really special team and I'm lucky to be a part of it. For the Newton development cycle I'd like to continue down the path of making Keystone more enterprise ready by advocating for solid, well-defined and realistic use cases for features that actually help end users. This includes support for Multi-Factor Authentication. Within Keystone I think it's critical that we finally deliver on our promise of a functional tests for our advanced features such as federated identify, notifications and multiple backends (LDAP and SQL). Lastly, we have clear cross-project deficiencies that need to be addressed. Creating a new standardized Service Catalog to improve interoperability, and changing our Policy and Authorization for a better user experience are critical. These are huge cross-project efforts that will need a lot of time and dedicated resources. I think we're getting closer to all of these goals with each passing release and would like to continue to take us there. Our core team is fantastic and experienced, I like to think I bring organization, structure and direction to the team. I’d like to continue to play to my strengths and accomplish the goals I have stated above. This can also be viewed in the election repo [2] [0] https://review.openstack.org/#/c/222766/1/candidates/mitaka/Keystone/Steve_Martinelli.txt [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/089387.html [2] https://review.openstack.org/#/c/292982/ Thanks, Steve Martinelli OpenStack Keystone Project Team Lead __ 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
[openstack-dev] [Keystone] PTL Candidacy for Adam Young
I am, once again, throwing my hat in the ring. No long position statement. If you know me, you know what I stand for. If you don't know me, you won;t be voting in the Keystone PTL election. I will state this: part of a successful organization is that the leadership position be held accountable. Leaders run unopposed do not then know if they continue to hold the support of their team, or if just no one is willing to assumed the burden. Don't worry about feeling loyal to the current PTL. This way, if they get elected, they know they truly have the project's support. With Condorcet, you will not mess things up. If you are committed to your project, run for PTL. __ 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
[openstack-dev] [keystone] PTL Candidacy
Hello everyone, I'd like to announce my candidacy for the Keystone PTL for the Mitaka cycle. The project has had great leadership the entire time I have been involved and I want to keep up the tradition. I've been working on Keystone for the past 2 years and I'd like to step up and take more of a leadership role. I have a long track record of technical leadership that can be directly applied to Keystone. This includes everything from project management to application architecture and many things in between. My thoughts on the direction of the project really boil down to landing the features we have already committed to, taking our experimental features and making them stable, improving general project stability and expanding our community. Goals for this cycle: * Land the features Several features that are very beneficial to the community are currently in development. We need to get them stable and shipped for Mitaka. This includes, but is not limited to federation, reseller, and centralized policy. There is also additional work that needs to be done with federation to take it from experimental to stable, like helping other projects adapt to the new requirements and making it a first class OpenStack feature. * Fix the bugs We have 293 bugs (at the time of this writing) that need some attention. Many have patches that need some work or just need reviews. Others need to be investigated and fixed. I'd like to cut this number in half. To do that I'd like to get people to focus more on them through activities such as bug reviews and bug days (more on that below). * Expand out testing Over the last two cycles we have made some significant advances in our testing practices. We need to expand on this cultural shift and even expand the focus on testing. The full test runtime needs to be cut by at least 50% to improve developer workflow. Near immediate test feedback is important for not breaking flow when writing code. This can be accomplished by refactoring test code to reduce unnecessary setup and focus on the code being tested. * Expand our community Being PTL isn't about me making all of the decisions or calling all of the shots. It's about facilitating the design and development of Keystone by working with the community. Through mentoring we can get more developers ready to be core to speed up our review pace. We need to work together to find ways to give more people the ability to contribute upstream. I do believe it's possible to make our thriving community even better. Thank you for voting for me as your PTL for the Mitaka release cycle. -- David Stanek __ 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
[openstack-dev] [Keystone] PTL Candidacy: Adam Young
My name is Adam Young and I am running for Keystone Project Technical Lead. Why I am running: I've been part of this project since it was in incubation. During that time, I've received the benefit of several dedicated PTLs. It is time for me to offer to do the hard work necessary to make Keystone successful. The Keystone project gets its name from the block on an arch that is put into position to make the whole structure self supporting. Remove any piece of the arch and the whole thing collapses. What is notable about a Keystone is that it has the highest degree of pressure of any block in the arch. The Keystone project fills that same role in OpenStack. It provides the means to make OpenStack capable of architectural feats not previously possible. But it also is the highest risk piece from a security perspective, and it is here that, as PTL, I will focus my attentions. My goals for Keystone: 1. Removing the bearer aspects of tokens 2. Better delegation mechanisms to scale the management of OpenStack. 3. Improving stability, scale, and performance. 4. Simplify integration with external identity sources As a member of the team, I have been frustrated by our inability to make progress on some of these key aspects due to workflow constraints. As PTL, I will look to restructuring the code approval process to increase development throughput while increasing the emphasis on quality. I've been blogging since before I started on Keystone. It has been one of the key ways that I have communicated the design, criticism, and techniques essential for Keystone's continued success. As PTL, I will continue to communicate, and to aid the other team members to communicate. Keystone needs to work with the rest of the OpenStack project teams. Here's the most important part; I'm, going to do this all anyway. It does not matter if I am PTL or not, this is how I will work. I'm hoping by running that I inspire other Keystone Developers to run as well. We've got a great crew, and I am looking forward to being part of it in this upcoming release. __ 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: 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
[openstack-dev] [Keystone] PTL Candidacy
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
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
[openstack-dev] [Keystone] PTL Candidacy
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
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
[openstack-dev] Keystone PTL Candidacy
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
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
[openstack-dev] [keystone] PTL Candidacy
Hello! I'd like to nominate myself once more as PTL for Keystone. Since becoming PTL for Keystone last release, I've gained a new perspective on the community which has changed my understanding of the PTL's role rather dramatically from what I thought I was getting myself into (by which I mean, I had no clue what to expect!). I'm now hoping to apply what I've learned towards making Icehouse a success. Namely, my involvement has shifted towards 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. As I'm sure many of you know, my primary interests in the project center first on stability and user experience, for developers, deployers and end users alike. That means I care a lot about solid documentation, self-consistent APIs, helpful error messages, intuitive code and logical tests. New features usually take a reduced priority with me, but I'm super enthused by the community's growing interest in federation, and I'm particularly looking forward to help solve a few of those use cases during Icehouse. Thank you for making Havana a success! I'll see you in Icehouse, -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
