 Hi welcome to another installment in the Newton design series. Today we're here with Steve Martinelli. Steve you want to go ahead and introduce yourself to the crowd? Sure. So like you said my name is Steve Martinelli. I'm currently the project team lead for the Newton for Keystone in the Newton development cycle. I was also the project team lead for the metaka development cycle as well. I work for IBM. I'm located up in Toronto, Canada. I've been affiliated with OpenStack since about 2012. Initially working on command line interface support for Keystone v3 APIs. Got me looking at Keystone itself and I've been in Keystone land ever since. That's how I got here. That's great. Can you tell us a little bit more about Keystone? Sure. So Keystone is OpenStack's central source for identity authentication access management. Anytime someone logs in that's Keystone anytime an API is accessed. Keystone is used. Keystone plays an important role in any OpenStack cloud. It needs to be reliable, efficient, and quick to respond. Great. So we're coming out of the Austin design summit here and wondering what were the top discussions for the team? So two really interesting discussions that we had were with the operators and it was the impact of making the Furnit token the default provider. Previously the default provider had always been the UUID token which is a very simple token and it stores your tokens in a database. Now with the Furnit token it's been around for a few releases now and it does all that validation offline. So it's a lot quicker and as a result Keystone will scale better. But now we're thinking about making it the default and this will impact both new installations and upgrades. So we're just double checking with the operators that is this okay? Because it's going to mean a few extra steps needed to set up the keys that are necessary for Furnit tokens. Another major hot topic that came up and this was with the greater kind of big tent projects and the infrastructure team was how can we use v3 everywhere? Keystone has two sets of APIs a v2 and a v3 and our v2 APIs have been deprecated last release. They have a for release cycle deprecation process and our new v3 APIs have all the goodness in there. There's a whole lot of awesome work being done there and a lot of operators want to take advantage of that. Trouble is some of the not all projects take advantage of the v3 APIs sometimes they make some janky assumptions about you know v2 is always going to be in the endpoint or there's a lot of hard-coded mangling happening in some projects. So what we're going to do is we're going to create a cross-project initiative and just kind of look at all the projects maybe not all the projects in the big tent but a few of the more core important core services and make sure that they are v3 ready. Yeah those are the two hot topics I'd say. Okay well important topics that's for sure. Were there other user needs or market needs that you all discussed as well? Some of the needs that we saw were that deployments were still struggling with adopting federated identity and seems we don't address some specific use cases and they're still a fair bit of complex setup necessary. So we're going to try to ease both those problems. The first one we're going to hopefully ease it by creating kind of shadow users. So previously in federated identity if you authenticated we weren't keeping a local copy of the federated user we were creating an ephemeral user you just kind of you know he wasn't really there but now we're going to create local data so that it's stored in there you can bring it back up and for the second problem we're going to start and start introducing some of the start moving some of the configuration options that were needed in federated identity and start putting them into actual HTTP REST calls instead have actual APIs for them. We think that'll make setup a little bit easier and we're going to see like that's that was probably one of the bigger problems folks have been having right now. Great and so as you look at the Newton development cycle how do you characterize your top three priorities? So for the top three priorities I'd say it is for the first one I think we want probably Python 3 compatibility. Making Python making Keystone Python 3 compatible is a goal that we've had for a while and it's looking like it can finally become a reality. The last hurdle we have is making our LDAP code and libraries Py3 compatible as well and right now we're at we've actually been working with the library authors to make to make this a reality of Newton so we've offered to make the libraries that we use Py3 compatible and as a result Keystone itself will become Py3 compatible. One of the second priority that we have is PCI support and this is we're going to start supporting configuration options to improve password compliance and strengthening. So a lot of deployments are still storing their users and SQL so and Keystone's database which is fine I mean a lot of people choose to do that but currently Keystone does not actually have any requirements for your password. It can be whatever you want it to be. So what we're going to start doing is we're going to have configuration options so that users if they choose to make their password if you know a deployment chooses to say all right all passwords that have to be eight characters and change every 90 days this can now happen or you can disable a user if they fail after five attempts in logging it. Those sort of support is something we want. The last one is online database migrations. Many deployers will like to see Keystone provide near zero downtime for a rolling upgrade and this is something I think we can have for our database migrations. Basically what we're going to do is we're going to draw a line on the stand and say from now on we will not be creating any database migrations that are going to drop or rename table columns or tables themselves so folks won't have kind of mismatched migrations with their current database. We'll only drop them when we're sure that the data has been migrated over and I think a lot I think this is going to be a lot a lot of projects are going to be doing this and you're going to see it more and more I think Nova and Cinder are doing this and you're going to see more projects kind of adopt this approach going on. Wow those are three pretty impactful areas that you guys will work on in the the next couple of months that's great. As you probably know the community road map that the product work group has been producing over the last couple of cycles is organized around a series of themes and the themes include scalability resiliency manageability modularity and interoperability. As you look at the work for the team in the Newton cycle how do you think that maps to those themes? I'd say probably stability I mean Keystone itself is a pretty mature project project now it's one of the I think it's the fourth or fifth project that opens SnackEd so stability and scalability resiliency I think all those kind of meet the themes that we're focusing on keeping Keystone as backwards compatible as possible keeping it as resilient and scalable I think given the fact that every project needs Keystone needs to use Keystone so it's got to be fast to respond but got to scale really really well and it's also you know you can't have any downtime with it so you know resiliency comes into play there and stability there's very very old deployments running Keystone and they want to make sure that everything is still going to work in the end we can't we can't have any surprises for users at this point we're a very mature project so I think those three themes scalability stability resiliency those two and would you expect that to continue into Okada or to add some additional themes to them? I definitely consider those to be the themes that we're going to be focusing on in Okada as well all right well thanks Steve appreciate your time and the information today and look forward to talking with you again when we get ready for the Okada design series all right thanks