 This is the Keylo update for the OpenStack Identity Program. I'm Morgan Fainberg, the Identity Ptl. You can find me on IRC, my Nick Morgan Fainberg. I just wanted to start by giving the brief overview of the OpenStack Identity Program's goals to facilitate API client authentication, service discovery, distributed multi-tenant authorization, and auditing as of the Juneau cycle. The Keystone Identity Program has adopted PyCADF, and we are making sure that we have full-featured audit support across all projects, as well as the Identity Program. The main priorities for Keylo for Keystone is to improve upon the specification process and ensure all major initiatives have associated specifications. We started last cycle as many programs did with the spec process, and we found that it was quite successful, and now it's just refining it, lightening up the template a little bit, light making it a little bit easier to work with, and improving the experience for both developers, proposers, and making use of them for employers as well. We definitely want to continue to work closely with the operators and employers of Keystone and ensure all their needs are met. We've made great inroads talking to a number of them, and expect to see them being more involved in the development process, including at the Keystone mid-cycle. We definitely want to work on eliminating the accrued technical debt in the code base. There's been a lot of it at this point. We have a lot of initiatives to simplify things, make things more maintainable, including how the split between identity and assignment works, cleanup of the token providers, etc. And generally speaking, we need to improve the operator, user, and deploy your experiences. And we're looking for feedback from all of those different parties as well, as working with those that we have good working relationship with to make sure that we've made the experience that much better. While we've been good at keeping stability for the Keystone API and generally speaking configs, etc., we want to continue along those lines. We want to make sure that all the interoperability that we've maintained between major versions of OpenStack releases continues. Notably, so you can run older versions of OpenStack with newer versions of Keystone and vice versa, though if you depend on a new feature in Keystone, obviously it won't be supported. We are working to improve all the integration with Keystone in the Python client libraries. Specifically, this revolves around inclusion of the session object and making sure that the experience utilizing these libraries is much better. As a note on the same topic, the Keystone client CLI is now frozen. All new CLI development will be occurring in OpenStack clients. We aren't looking to deprecate the CLI support in Keystone client itself yet, but no new development will occur there. Similarly, the V2 API for Keystone Rest API is frozen. It is not yet deprecated, but we are making a big push to get everybody to the V3 so deprecation can occur in the next few cycles, but will not occur in Keylo. Testing is going to see some significant improvements during the Keystone, sorry, during the Keylo cycle. We are restructuring the layout of all tests to be more logical, less of everything lumped into one file and hard to work with. We are working to improve, utilize, and develop a full functional test suite. Most Keystone tests already cover what the functional test suites for other projects do. However, we want to make it possible to use these functional tests across any OpenStack deployment and verify that they are. Profile deployment meets the standards that we run the upstream continuous integration on. We are looking to include more third-party continuous integrations, specifically around integrating with ADFS, Active Directory Federated Services, and continued support of DB2 among other such third-party projects. We are looking to improve our testing coverage, as always. More tests, better coverage is always better. We have eliminated the download of Python Keystone client before while running unit tests, and are looking to improve the story so that Python Keystone client is not actually needed to maintain test coverage. Federated Identity is a huge part of Keystone at this point. There was a large amount of success that happened with getting Federated Identity into Icehouse and similarly moving into the basic support for the Keystone-Keystone Federation via SAML2 in Juneau. We are looking to continue to improve upon this success, improve the deployer story around it, make the deployment options clearer, better, significantly improve the documentation around it, and then, as stated, maintain a full set of test suites, including third-party CI where possible. Hierarchic Comomty Tendency is now in the Keystone tree. It is supported fully as of Keylo 1. This is the basic implementation supporting the project hierarchy. We will continue development and improve the support of the hierarchy through the Keylo cycle, which will include a reseller-type use case allowing for shared resources throughout the hierarchy and limiting visibility and resource access within the hierarchy, as well as general improvements making Hierarchic Comomty Tendency a better tool for all projects to develop and features upon. Tokens have had a number of issues throughout the lifespan of Keystone. We are working to improve tokens. This will include persistence issues, size issues, and improving how tokens can be utilized, limiting access for certain types of tokens. A lot of this is technical that clean up around the token providers themselves, making it very easy to develop your own custom token provider and providing a few new providers in Tree that will improve the deployer experience. We are looking to provide in the Keylo cycle at least one provider that does not require any persistence of the token itself, which will eliminate all SQL table bloat issues as well as issues that have cropped up around the memcached token driver. We are looking to also eliminate the need for the complete catalog to be in the token. This has mostly been done within Juno. At this point it is making sure that all the projects and client libraries properly support the session class as described earlier, and that will take care of being able to determine the catalog without needing to encode it directly in the token. During the Keylo cycle we expect to also have full support for what we are calling token constraints. This is a limitation on how tokens can be utilized such as requiring a X509 client certificate or Kerberos or other form of authentication when interacting with an endpoint. And we are also looking to move away from the token revocation list and to fully supporting the revocation events, which will also lighten up the amount of data stored in Keystone relating to tokens. The major change to the Keystone REST API is we are trying to eliminate the concept of an extension. Keystone's API will no longer have an entry extension. We want to move to a simple classification of functionality, whether it's a functionality that's directly part of the REST API or functionality that is internal to Keystone itself. These three classes would be stable, experimental or out of tree. Anything that is stable will be treated as stable such as the REST API will maintain compatibility across versions. Experimental means that we are going to do everything we can to avoid breaking the contract. However, the contract is not yet fully codified or set in stone. If we have to make a change due to an oversight, we will. Most new functionality will originally be added as experimental and then be promoted to stable once we are happy with it. Promotion to stable usually will only occur after a full cycle of being included in tree. Then out of tree code will provide a better form of plugability for developers to include their own functionality within Keystone. However, with the out of tree code, there is no guarantee that it won't change over time or that it won't be broken over multiple releases of OpenStack. This allows the same flexibility we have today without requiring us to include everything that everybody wants inside the Keystone tree itself. Some exciting changes to how policy is working in OpenStack was the conversation started during the Paris Summit. The general gist of it was we want to support centralization of the policy.json files. Keystone will initially be the location where these files will be centralized to. So endpoints will be able to request their policy from Keystone. This allows us to support in the future dynamic policy files, which allows us to ensure that the default rules are the same across all projects, all endpoints, rather than having to have varying assumptions within each end point. Glantz will have the same concept of what a project admin is as Nova would. We want to remove the hard-coded isAdmin rule and move to a better RBAC type default policy. This will make it so that it is possible to handle cases where a project admin can only interact with resources associated to their project. A domain admin can only interact with resources within their domain. And the goal is to make that a uniform default across all projects, maybe beyond the KiloCycle to get there, but we are starting all the work here. And the Keystone team is assisting in maintaining the rules engine, the Oswell policy file. And we are working to help ensure the graduation of that to a full-fledged external library. And that's it. That's the update for the OpenStack Identity Program for the KiloCycle. Thank you very much.