 Hello and welcome to the Newton design series interviews with PTL's. I'm Kenny Johnson here with Graham Hayes of the designate project Ma'am, could you tell us a little bit about yourself and your background with OpenStack? Yeah, sure. I'm Graham Hayes and the PTL for designates for the Newton release cycle. I work for Hewlett Packard Enterprise in Dublin, Ireland as a senior software engineer. I've been PTL for the designate project now for this cycle and the last cycle and I was a core for the previous couple of cycles previous. Awesome. Cool. Can you tell us a little bit about designate and what it does? Sure. So designate is a consistent API that runs in front of different DNS servers. So no matter what DNS server the employer has, the API for end-users will be the same. Because it's easy to consume API and we have features that allow multi-tenancy or multiple different groups to share the same DNS servers. It makes it a lot easier for employers to allow self-service DNS. Traditionally, getting a DNS record created or updated would involve a service ticket or talking to the support desk, but using designate, it means it's a fully self-service operation so users can create and delete records and zones as they see fit. We also have a lot of integration. Merge this cycle that allows the automation of the creation of records and whenever you boot a VM having the DNS name for the VM created at the same time and when the VM is deleted having it also deleted. That's awesome. That's great. So coming out of the Austin Design Summit, can you tell us a little bit about what topics of discussion and outcomes from those discussions were? Sure. So one of the major topics we worked on was we have a put component called MiniDNS that unfortunately is quite slow. So one of the things we looked at is how we can improve the speed and that's driven into a wider community discussion that's happening right now about whether or not we should rewrite it in a different language than Python. So we would prefer to be able to, but that discussion is still ongoing, so depending on the outcome of that, we'll either have to optimize the current and place code or replace it with a more native code. Another big topic that came up was we currently have a couple of services that are just there to do repetitive tasks and we wanted to amalgamate them into a single sort of worker model style system so that you don't have to scale up or down different services individually. You can just scale your pool of workers for end users. So since the code for that's been progressing very nicely, so hopefully we should get that merged in the near future. And then one of the biggest things we got was docs. We need to, end users always want us to improve them and we can see that from the user survey as well. So one of the things that we're pushing for this cycle is to improve the docs that we have and make sure that we put docs into the other places in OpenStack. So there's the operations guide, there's the user guide, there's the install guide, and then there's the API guide. So one of the big things we want to do this cycle is just to push all of our docs to the right places and integrate in all of these different sections of docs. That's awesome. It sounds like the docs work is really a response to your evaluation and review of the user survey. Can you talk about how the other work that you described and other discussions tie into feedback you've heard from users or operators? Unfortunately for us, we didn't hear a huge amount back from the users and operators in the discussion, in the user survey. But we have a lot of very vocal users who appear in our C-Channel and one of them is the worker model is particularly one of them that we were adding extra services and it caused operators to have to worry about what to scale so that's part of the reason we're going to work a model. It also makes tasks a lot cleaner for us so that developers when they're working on it makes it easier. One of the topics we did hear back from the operators from from the survey was what other DNS servers that they wanted to have included in Designate. We've actually implemented two out of the three top requested ones so far. There wasn't so much a topic at the Design Summit. It was just, okay, yes, these are things we need to go do so we've gone and done them. That's awesome. That's great to hear. There have been some identified themes across the OpenStack releases and I'm wondering if you can speak to some of the designate work that fits those themes, themes such as scalability, resiliency, manageability, modularity and interoperability. Sure, so the scalability one having a single service to scale will make it a lot easier for us for end users or operators to scale the scale designate. And it'll also make it more resilient because if losing one of the services now won't necessarily mean that you've lost half of all the tasks that that particular service used to provide. The tasks will still run. It'll just be slower and interoperability is something that we're working on a lot. We're making sure that our API is the same across all of the clouds and writing tempest tests to ensure that we don't break it for end users as they go forward. And that whenever the public cloud operator stands up designate, they can run this at a tempest test to make sure that they are the same as everyone else who's also running it. That's great. So I guess last question, putting on your crystal ball and thinking about what might have been in the Ocata cycle. Can you give us an idea of how you see those themes carrying forward into Ocata? I can see scalability anyway coming into Ocata as people start trying to deploy this into sort of global scale private public clouds. I think that interoperability, we have a sort of federated plugin. So if you run designate locally, you can have a federated to once that's run on a global scale. So you make the changes locally and push the other changes get pushed up to the global designate install. And I think there'll be a lot of work around that to make it a smoother experience. But that's crystal ball. Things can help us change so quickly and so much that we could have users chatting about we're doing something else wrong or they need a brand new feature. And we prefer to go with what users want and what we think the problems are. Yeah, that's great to hear. Also, thank you for your time today, Graham, and thanks to all listeners for viewing the Newton design series. Thank you.