 We can probably go ahead and get started got a full room. This is exciting. My name is Lance. I'm an engineer at Huawei And I'm Colleen. I'm an engineer at Suza and today we're going to go through the Stein project update for Keystone So real quick. We'll just kind of go through an introduction into what open-stack identity is We'll talk about the things that we accomplished in Rocky We'll discuss what we're working on today for Stein and then we'll get ahead to the tea release We'll also spend some time talking about cross-project initiatives will tell you how you can get involved and Then share some other related talks and sessions that you can find us at So open-stack identity is an API reference and Keystone is an implementation of that API reference It essentially came out of the need to reduce duplicate code across open-stack services back in 2012 And it fills a pretty important role in open-stack It's meant to supply end users and services with information about identities and the authorization those identities have Keystone can also sit in between open-stack and other places that your users might come from like LDAP or external identity providers This is some of our most recent user survey results taken earlier this year and we like to include this in our project update because It really does a good job of showcasing why we spend so much time in certain areas of the code But you can expect to see these themes pop up through our presentation So Rocky was a really busy release for us first and foremost. We introduced a couple of additional default roles So instead of just having an admin role, you now have member and reader by default We'll touch on what that means for our Stein work a little bit later We also made several improvements to our unified limits API These are mainly to make it more consistent with the rest of Keystone's API and to make it easier to consume We also implemented a Hierarchal enforcement model so this model actually has opinions about how limits for resources should work across the tree of projects Or a hierarchy of projects And this is supplemental to the flat enforcement model that we originally introduced in Queens when we implemented the unified limits work We also ended up embarking on a really large refactor to remove Keystone's dependency on Python paste and paste deploy This is ultimately because we were removing a bunch of code that was v2 specific for Queens and this gave us a good opportunity to remove some homegrown API dispatching code in Keystone so we've transitioned that to working with flask instead and This is pretty transparent to end users, but it does a couple of really important things It simplifies our code base, especially our API layer It makes it easier for people to understand and it also makes it easier for us to implement some new features specific to Federation and rolling out more granular policies We also helped bootstrap a new Oslo library called Oslo limit And this is helpful for services that need to consume unified limit information out of Keystone and run that through Enforcement checks. I'll touch a little bit more on this when we get to the cross project section We also proposed and merged several patches to clients that get them up to speed with some of our newer features like system scope system roll assignments and Unified limits so you can start consuming those features using Python OpenStack client Python Keystone client and OpenStack SDK So I'll talk a little bit about what we are planning on doing for this cycle and what we've already accomplished this cycle So the first thing is we're going to be building on all the work We did for unified limits last cycle by adding domain support for unified limits, which means that to level limit hierarchy that we have now Currently that only supports two levels of projects We'd like it to be so that the top level could be a domain since that's a pretty common way of organizing your resources So we'll be working on that this cycle The next step for application credentials, which is a feature we introduced in Queens is to implement Fine-grained access control and we're going to be doing that by adding API capability lists as a property of an application credential so that a user when they're creating their application credential can really restrict the application credential to being able to only Call certain APIs which gives the user a lot more control over how this credential is used Even more so than what keystone roles will allow since those keystone roles are not very flexible right now in based on the feedback from the user survey and In working with various edge computing groups, we're going to be stepping up the priority of improving our Federation implementation So stomping on bugs fixing some usability issues getting real CI in place and Improving our documentation so that we can actually give a really good Big picture overview of what you can accomplish with keystones Federation We are just about in the last couple of weeks. We've just about finished Merging the rest of the flask transition work So we're just going to be focusing on making sure that that Any bugs that crept in during that refactor are stomped out and making sure that that means remains completely transparent to the end user as always we're going to be working on trying to fix policy by Working with the rest of the projects to implement Default policies that will allow for a real read-only role out of the box across the board Making that a lot easier for operators to configure. We're also going to be working on Making the naming conventions for policy rules more consistent. So that's less of a headache for operators to configure as well We'll also be working with the rest of the community to Get projects to be able to consume the new system scope So that we can really start moving away from the admin this problem that we've been having for such a long time with pure project scope We recently just merged Support for multi-factor auth receipts. This is a new way of this is going to improve the client experience for multi-factor authentication because it gives Clients something to follow up on so that they can actually do sequential authentication steps Which is going to drastically improve the end user experience for doing two-factor auth multi-factor off and Finally, we're going to implement JWT or Json web web tokens as a new token provider alongside the existing for net token provider and we're doing that because JWT is a more globally known token standard Services outside of OpenStack are going to be more able to understand and consume it and it could help us down the line with improving multi-region and distributed keystone setups Because of because it has the ability to do asymmetric validation, which is helpful so looking ahead to the next release and beyond that Something that we've been talking about for a little while is turning What it would take to turn keystone into an identity provider proxy and making it actually usable and useful outside of an OpenStack context and so that will lean on a lot of work to Improve and expand our Federation implementation and get keystone to natively understand Federation protocols like SAML and OpenID connect We're going to be continuing to build our limit hierarchical models. This will lean on Getting the other projects to consume the keystone limits And getting a really good understanding of how this Consuming and enforcing is going to work in the other projects and getting a good proof of concept in our OZO library for consuming hierarchical limits we're going to continue to work with operators and edge computing groups on improving our multi-site support and Figuring out where the gaps are for those types of use cases and building out some reference architectures for that We're going to be striving to apply for the rolling upgrade governance tag by finally reviving our rolling upgrades testing And getting those tests to be actually voting so that we are confident in our rolling upgrade support and As always we're going to be improving policy working on cleaning it up making it easier for operators to use easier for End users to consume and understand So I wanted to touch a little bit on some of the cross-project initiatives If you can already tell We've got several of them in place one of the more recent ones as Colleen mentioned is coming up with a consistent policy naming convention And this is because no matter what open-stack service you look at everyone's kind of got a different way to name their policies So a few weeks ago we kind of stepped back look at all of the different policy names and types that we have out there And came up with a convention that should work for everybody So we documented that formally and now we have something to work towards So this is going to help Especially with operators to at least understand what they're dealing with when they're overriding a policy And then also the deployments that might be shuffling their policy enforcement checks off to an external system It'll give a more consistent look and feel to end users that might be accessing those policy names We're also continuing to push the adoption of unified limits right now We're working closely with Nova specifically to get a few of their resources into Keystone by the end of Stein We're taking a similar approach to education around scope types with Keystone so system scope domain scope and project scope and how those scopes can Help services better protect their APIs and allow more granularity. So what this is ultimately doing is Giving developers the tools to expose more of what they do to end users in a safe and secure way Going hand-in-hand with that is that better default role support because we have those roles in Rocky We can start transitioning our default policies to consuming those So now you're getting that read-only roll out of the box You're getting a member role and an admin role that I'll kind of do what you would expect across the different scope types This will make it easier so you don't have to go and override a bunch of policies just to get a read-only role in your deployment so if you if you'd like to start getting involved and start being part of the discussion a couple ways you can do that are we have office hours on Tuesdays after our meeting our meetings at 4 p.m. UTC and our office hours take place after that. So that's a good chance to find a lot of us there Get in touch with us start some discussions or to help us stomp out bugs Work on some features that kind of thing We also do every Friday or most Fridays We do a report to the mailing list and we have an ether pad where we can Collaboratively compile a summary of what we talked about what we did that week So if there's anything that you feel is is noteworthy and worth worth mentioning to the rest of the mailing list We can visit that that ether pad and add some notes to there So some other places where you can find keystone related talks and sessions This is a list of relevant forum sessions that we have for keystone The one that I kind of want to note is we have project onboarding right after this so there's anything that interests you or you want to learn more about it or Want to get involved in a particular initiative. That's a great time to do it And here is a list of related talks Specific to keystone. There's one going on right now Along with this session, which is the open stack policy 101, but that'll be recorded if you want to go catch up on that later That about does it for our project update, but does look like we have some time for questions So if you do have any questions, we can answer them now That's a good question. That hasn't been on our radar, but I can make a note to follow up with that team directly though. Thank you Anything else? Comments questions concerns. Cool. Well, thank you so much for attending. We appreciate it