 Hi. Welcome to the Introduction to Designate talk. We are going to today go over what Designate is, how you can use it, and how it works. So my name is Graham Hayes. I'm the Designate PTL. Tim Simmons is a member at Designate Core, and Eric Larson is one of the other developers on Designate. So we're going to go over a quick overview of what it is, how you can use the API and Python bindings and other libraries to interact with it, how we work with DNS servers, and then how you can integrate it with other OpenStack components. So Designate is a simple, easy-to-use REST API that can interact with multiple different DNS servers behind the scenes. It allows you to choose whatever DNS server you want to use and present a consistent API to your end users. So we have a small number of services that we use to make all this work. We have an API service, which is just a very basic service that takes your input, validates that it's supposed to be correct, and makes sure that you're authenticated to your natural user and passes it to our central process. This is where all the business logic happens. So this is the service where we write everything to the database. We make sure that you have the correct permissions to do everything. And it's where we dispatch the rest of the tasks to the system. Central then interacts with our pool monitor service, which loads up pluggable backends. So you can decide which DNS server you're using. And this is where they plug into the system. The backends then are responsible for creating and deleting zones on the servers. And then pool monitor will then use a service called MiniDNS, which is a very lightweight Python service that talks the DNS protocol to push out the DNS information for the zone to the servers that your customers will use using the DNS protocol just for the simple zone transfer. We then have Nova and Neutron can also interact directly with their API. Or you can listen to events off of the notification queue to perform actions within Designate to create and delete records. So Designate is there because it's a very important part of how the internet works. Without DNS, it's kind of difficult to get to services. Most people can't remember IP addresses for v4, and nobody can remember IPv6 addresses. It's a lot easier than traditionally in enterprises or most places to get a DNS record created. You have to create a ticket, or you have to go to a self-service tool that may or may not give you permission, or you have to edit files on a DNS server manually. It's all very complex, and it means that there's a bottleneck of the people who are allowed to actually create the DNS records. With Designate, you can push that responsibility out to the users, so they're entirely self-service, which means that it reduces load on your IT teams and gives users the power to do what they want. So that's an overview of how we work. Eric is going to go through the best way to work with us. Right, so in order to use Designate, you actually want to make requests to it. So there's three ways you can actually talk to Designate. There's a REST API, so it's free standard HTTP REST conversation you can have with Designate. There's Command Line Client, and there's also Python bindings, so we're going to go through each one and give you guys a quick overview of how that works. So starting off, we have a REST API. There is a version one, but it is deprecated. So don't use it. Don't look at it. Don't try it. It's not worth your time. There is a V2 API, and that's stable, and this is the one you should be focusing on using. This is one that Command Line Client uses. This is what the Python bindings can use. This is the latest and greatest. There's also an Admin API, and that's for doing administrator tasks. So prime example is you can do things like assign quotas to a tenant to say, oh, you can only have X many zones, for example. So here's a quick example. This is a post request, an HTTP request, to create a new zone. So this is creating the zone example.domain.org. It's in its email. So we go and we make that request to, you can see the version 2 API, and so it's just simple. Jason should be pretty familiar to you guys if you guys are using anything in OpenStack. So and this is a response, a little bit small to read. Hopefully you guys can read it OK. But one thing I want to point out is you see near the bottom, you see status pending. And so that's because the API is asynchronous. So what you would do is you would make your post request, you'd get this response back. You can see in the links there's a self, and that provides you a URL that you can then pull, and you can pay attention to that status value to see when that domain was created. And one thing to note too is that when you do get a status, eventually if active, it actually should be able to be resolved on the DNS infrastructure. We should each be able to do a dig and get a result back. So here's another example. So we're going to go and we're going to create an actual record. And just if anybody can see an error with this, the problem with this request, go ahead and shout it out. 1,000, that's right. So we're trying to do an IP address of 1,000.0.0.1. And that's obviously not a correct IP address. So we'll see what the response looks like. So here we get an error. We actually get a 400 of that request. And you can see that we try to make an effort to give you a message to say, hey, 1,000.0.0.1 is not a valid IP for address. So where possible, we really do try and give you guys good error messages so you can act accordingly and fix things when they're broken. So next up, we have a command line client. So this integrates with the OpenStack command line client. So basically this fake shell here I'm showing you, you see we have, we install the Python designate client package. And then when you install the Python OpenStack client package, that installs the plugin that will allow you to talk to designate. So for example, you would log in and have your credentials with the OpenStack client. That would go in authenticated keystone. Your service catalog would have the endpoint. And you would be able to use that then to do things like the next thing, where you see OpenStack zone create. And there you can go and create a new zone. Or for example, OpenStack record create. So there we were creating a new A record. So there's also endpoints for things like PTR and a couple other things like that. Finally, there's Python binding. So this allows you to import classes so you can talk to designate within your code, within your Python code. This does use the version 2 API. And again, you can see here that we're importing a keystone client in order to do the same sort of negotiation with keystone to find your service catalog, the endpoint to make a request. So you can see here we're going to client. We're instantiating a client using a session. Then we're going and saying, using the client to list the zones. And you can see there I'm passing in a criterion. So that's, for example, how you could filter what sort of zones you wanted to get back and everything. So here we're filtering on the namework, example.com. So with that said, I'm going to pass it over to Tim. He's going to talk about how we work with DNS servers. Thanks, Aaron. So Grant told you what it was. Eric told you how to use it. I'm going to tell you how it works. This is the meat and potatoes right here. DNS servers are kind of complicated. So a lot of DNS servers that are still in use today started to be written 80s, 90s before anybody in this room was alive. And it can be a little weird. It can get a little janky, y'all. And there's a lot of different ways that people choose to run it for different cloud things, small things, big things, medium things. And Designate really tries to make an effort to work with all these things. So the way you do that is three simple words. Flexible, you've got to have a simple API that works kind of universally across all these different services. You need something scalable. DNS outages are not a good time for anybody. Everything is gone because people don't know IP addresses. And it needs to be simple because DNS is one of those things that just works. So you've got to keep it on the DL, keep it real simple. So one of the ways that Designate does that is this mini DNS component that Grant talked about earlier. So when you're trying to work with updating a large amount of different types of DNS servers, you really want to converge on one simple protocol. And luckily, the vast majority of them implement this same thing. It's a Notify and an AXFR, which is a zone transfer. So mini DNS, which is a very small DNS server that's kind of just based on those simple tasks, like sending Notify, answering the queries for a zone transfer. It's part of the Designate project written in Python. And it acts as the master in a sort of master slave setup for DNS. There's one notable exception that it doesn't act as a master. And I'll talk about that in a minute. Very horizontally scalable. You spin up as many of these things as you want and just hit them from any angle. And it's backed by the Designate database. So that's kind of the bottleneck on scale. And this is really great because it allows Designate to be in control of the actual DNS part of updating these servers, rather than trying to abstract that in any way. You're kind of going right to the meat and the bones of it. Mini DNS is really great for updating zones because they all implement that same Notify and AXFR type thing. But creating and deleting zones, which you don't really do so often, you're not going to create MyCompany.com and then delete it and create it again. Nobody wants that. But that can get a little weird. So some services are going to want you to call shell commands. Some want you to do database calls. Some want you to go and create and edit a flat file. So Designate's pool manager, which is responsible for orchestrating the proliferation of that DNS data across all the servers, handles the creation and the deletion. So for bind, it's going to go and call the RNDC calls that need to be called. For Power DNS, it's going to go and make the necessary database inserts. It's very simple, which you'll see in a demo in a minute. And the pool manager also has some really nice things for keeping DNS eventually consistent. So things that didn't get propagated the first time, those net split or anything, those will get retried until they work. And then it has a mechanism for kind of going back in time a little bit and ensuring that the things that we thought got there actually did stay there and are still there. There's also another component that's completely optional. And this is for people who absolutely need 100% control. So usually, Designate operates on the master side. And it controls that side of the equation. But if you have a weird DNS server or a weird firewall or scaling situation, maybe your DNS server doesn't implement some feature that Designate does that you like, you can deploy this agent. And it just talks to the other side of DNS protocol, kind of a reflection of many DNS. And then it just gives you a totally generic interface to say, OK, what do you want me to do when you have a create event, an update event, or a delete event? You can go through and parse out the record sets and do something weird with that. Or you can throw away parts of it that you don't need. Or if you've got some really weird API that the DNS server that you want to use has them, as long as you can do it in Python, you can do it here. And that's really nice just for, like we said, a flexibility perspective. And that usually runs on the DNS server itself. But there's no reason that it needs to. You could be making remote calls somehow or anything like that, like, say, very flexible. So we're talking about the case where mini DNS is not the master. It can actually be a slave. So there are some circumstances where people might want to hold the DNS cards of their company close to the chest, so to speak, but also have all the benefits that a big cloud's DNS services can provide. So they might keep the zone file under lock and key and allow mini DNS in designate to take that zone via the same protocols that it would push out to its slaves and then proliferate just that copy of the zone. And that's really powerful if you have a big customer who's very cautious about security or somebody who wants to have redundancy in their DNS providers. It makes it really easy because, like I say, it's the standard DNS protocol for getting those zones out. So even though the demo this morning at the keynote did not go as planned, I'm going to attempt one here for you. So I wrote the code beforehand so you don't have to suffer through that. I wrote a really simple DNS server on the flight over. And I'm just going to implement a really simple driver for that. So I'm just setting up some parameters here, the host, the port of the DNS server, which is 53, shouldn't be 53, 58. That's a typo. And then this server has a REST API, which if you're watching anybody who maintains a DNS server, please give us one. I just wanted to put that out there because that doesn't exist, and it really should. And so we've got the we're instantiating the plugin there, the back end plugin. And then literally right here, right here, this is it. We're going to create the zone, which is just using Python requests to send a simple post. You can see there and then send the notify, which is going to tell MiniDNS to say, hey, tell that DNS server that I've got an update for it, and that it should transfer and get any updates that happened since its last change. And then if we wanted to delete the domain, even simpler, send a HTTP delete. Very simple. So let's do it. All right, here we go. So I've got, oops, this is a good start, guys. So I've got designate services running here. You can see, talked about earlier, API central MiniDNS pool manager. And then I've got the client that Eric was talking about. So we'll see that. Oh no, we got no zones. So let's go ahead and create one. What should I name it? Demo. Good call. Let's call it greatdemo.com. And then what's your email address? We'll just use mine. We go, oh no, I've done a bad thing. See, this is going great for realsies this time. So this kind of looks like the API slide that you saw earlier from Eric. You see status pending. Can you actually see that? Yeah, that's nice and big. You can see a status pending there. And I'm going to take you through here. This is the logs from the pool manager service. There we go. So you can see here, we were going to go and call a create domain. So it's going to call into that back end that you saw earlier to do the actual create. And then there it was sending the notify that you also saw. And then after it did that, it said, OK, I've done it. Now go and make sure that it actually happened. So it went and sent an SOA query to see that it was happened. Look at that. It even failed the first time, which happens. You're pushing DNS updates a long ways. Maybe it's not going to happen the first time. It's going to take a second. Then it went and sent another one. It retried. You see, retries. And then we had success. So we ended up creating the domain successfully. So let me just show you. It's a pretty bad DNS server, y'all. All right, so no error. We have successfully created it. We've got everything that we put in there. You see my email. And it's done. And you can see now that if you go and list the zones again, that it has gone active. So that should give you some confidence that it was pushed out everywhere it was supposed to be and that it's live for resolution. So DNS, thank you. So much. We did it live, y'all. All right, Graham's going to talk about the future. Thanks, Ted. So where is Designate going is the next thing. We are planning what to do for the next six months, obviously, here at the moment. And what we're looking to do is integrate more and more with other open-stack services. So tomorrow, actually, there is a talk at 9 AM. I know it's early. But there's a talk about the integration of NOVA and Neutron at Designate and how you can auto provision DNS records and reverse DNS records from NOVA and Neutron just by providing a name to a server. We're also looking to do new features. People are asking for things like DNS stack, GOIP. And we're looking at these right now. If people have preferences on what we should be doing, please tell us. We value feedback. And it's very easy for engineers to see something we think is cool and lose the big picture of what people actually need. So feedback is welcome. We're also working on, obviously, stability and making sure that everything is rock solid. We're pretty good right now, but there's always room for improvement. And we are also looking at getting more and more DNS servers supported. So if you don't see a DNS server in the list that we support, let us know. And we can start getting that driver implemented. As Tim showed, it's pretty simple for 99.9% of cases. So if we can get it into Designate, we will. Tomorrow as well, if this piqued your interest, the three of us will be attempting another live demo. But it'll be on 50 people's laptops at the same time. We have a workshop where we will be showing you how to install and operate Designate. So we have a virtual machine where you'll be able to interact with Designate directly and see the horizon panels and how you get it installed and what you need to run it. So that's tomorrow morning at 9 AM as well. You've got to decide between seeing the cool new integration stuff or the three of us making idiots of ourselves in front of a room of people. But with that, is there any questions? Any questions at all? Yeah? So there's a mic up front that's probably the best. So everyone else can hear? Since I won't be attending tomorrow's talk about integration with Neutron and Nova, because I will be attending the hands on, how does it fit with the rest of OpenStack? I mean, can it be deployed independently from the rest of the system and still getting events from a previous version of OpenStack? That's what I'm interested in, because we have, let's say, that we have an older version of OpenStack deployed. And we're interested in adding a stable version of Designate, which wasn't in the release cycle of that version of OpenStack. Yeah, we're pretty, as long as the keystone is pretty much under the hard dependency for general usage, as long as you can be deployed, as long as there's no conflict. If you're installing the same control plane, as long as system packages don't conflict, or if you're deploying a separate control plane beside it. No, I'm talking about separate machines from the control plane. For the integration, we have a previous thing called Designate Sync, which can listen off the events key of Nova Neutron. That should work as well with the older versions. Those events haven't changed their schema, really, in the last couple of cycles. So the notifications have been quite stable from, let's say, Juno. Yeah, I think they've changed massively since Juno. No, yeah, the means we haven't. Yeah, I think the change, the stuff that comes through to us that we listen for haven't changed. OK, thanks. No problem. Any other questions? Keep clapping yourselves. You can get it going. You got to get it going. Thank you, guys. Thanks a lot. Thanks, Joe.