 Okay, my name is Mike Suska, like Josh said, with the Rackspace Cloud DNS team in Austin, Texas. I've been there almost exactly two years, two years this month, actually. All right? Oh, thank you. So I'm going to talk a little bit about DNS at Rackspace, the way it is today and the direction we're moving and why. Then I'll go on to introduce the OpenStack project. First, a little bit about DNS. It's a telephone book of the Internet, basically. You type in a URL, CNN.com, for example. It translates that to an IP address. It's a distributed database. It's asynchronous. As anybody who's ever tried to update an IP address in DNS and waited for it to propagate is fully aware of. It can take a while sometimes to putting on your TTLs and stuff. Okay, Rackspace right now, our DNS has 1.65 million zones in it, 15.7 million records. We have an anycast network and that basically means we broadcast the same IP address for our primary DNS servers and users get routed to the closest data center to them. So right now we have name servers in our Dallas, Washington, Chicago and Lyndon data centers and we'll have Hong Kong and Sydney up here really soon. And maybe one of these days Oregon too. We have a public REST API on our DNS, which is really nice. We did that about three years ago before OpenStack, so it's a homegrown solution done in Java. We did that because at the time, to update DNS records, people had to call in and 8% of our support volume was actually DNS related. So the API has been really, really nice. And we have a control panel hookup too, and that's how most customers actually get into it. Like I said, the Rackspace Cloud DNS API, actually it was launched two years ago actually, used to manage cloud zones and records. The managed customers still either have to go through support or they go in through a different control panel they have in something we call Core. It's the second most popular feature in our control panel behind cloud servers. So people go in and spin up a cloud servers and they almost always go in and set up their DNS records. It's very popular. It's doubled since January 2013. Usage is really, really picked up on it. Customers really like it. It has pretty good uptime too, 99.999%. Actual DNS infrastructure has 100% uptime over the last two years, so we've had no downtime at all, even with DDOS's and everything. It's pretty stable. So if it's so stable, why would we want to change it? We want more features, we want faster development and simpler deployments. Right now, DNS at Rackspace is spread over three different teams with three different applications. We have the REST API that my team runs. We have a middle layer called Autohost, which is a Ruby on Rails application, and then we have the back end, which is managed by the data center folks. So that means anytime we want to add a feature or fix a bug, add a new record type, we got to coordinate over three different teams. That's a pain. It's also, it's a very large infrastructure. I mean, each of these environments, each of these three different teams have their own setups with firewalls, load balancers, dev, QA, staging, disaster recovery, production environments, hundreds of machines. It's a giant complicated system. So what could we do to fix this? You know, there are several things we could do. We could centralize ownership of some of those layers, so they're reporting to either one or two different teams instead of the three we have now. We could green field. That's always fun, you know, just redo everything from the ground up. We considered that, but we decided to adopt designate. Now designate used to be called moniker, but turns out we didn't know it at the time there was a company, DNS company called moniker, so we had a few legal issues and had to be changed. Now a little bit about designate, it was actually starting up by Rackspace by HP in 2012. Hopefully we'll be incubated next month as an official OpenStack project and it's actually in production right now as HP Cloud DNS. So it's actually production ready. As a general features you expect from an OpenStack DNS thing, provides DNS services with an API, provides authority of DNS resolution. That means it talks all the way down to the primary DNS servers. It's very, very modular. We can put in different back ends for different databases. We can put in different DNS servers like bind or power DNS and it's integrated with other OpenStack components. So, you know, like you can get plugins for Neutron or whatever to automatically add DNS records when you spin up cloud servers and stuff from Nova and stuff and hopefully Trove here soon too. So this is the architecture. It's like a lot of OpenStack stuff. We have an API and it all talks on a rabbit MQ bus. We have optional components called sync which gets Nova Neutron events. The main central part is called central, a designate central. That's where the actual it takes stuff from the API and puts it either puts it into a database for the record keeping and then pushes it out to the DNS service. But here's the same thing I just talked about a little bit more detail. The API furnace called designate API is based on Oslo and Flask. Now that is currently being reworked to use Picon instead of Flask. Designate Central is the core business logic component. It has all the basic DNS record types and everything in there. And that's the only piece that talks to the database. And it talks directly through it using a Python library. So it listens on the rabbit MQ bus to get its event notifications. We have a public plugable storage for the database. Right now we're using SQL Alchemy. And we talked to SQLite to MySQL. That's what we have right now. We'd like to expand that with MongoDB or some other stuff. And we have plugable back ends with interfaces to the DNS server, simplifications for power DNS and bind 9 we have right now. The bind 9 interface is a little rough. We're working on that right now to get that to work at the scale we need. Future V2 API being worked on right now. It's adding new features like record sets to be kind of similar to what Amazon's Route 53 works. DNS sec is something we want. Failover is something we're also actively working on. So there's a failover record so you can send a monitoring event to it. If you have a data center go down and it will automatically update the DNS to route things to the other data centers. Open stack incubation, like I mentioned, hopefully that will be coming next month in Hong Kong. And improved bind support, which is what Rack Space in particular is really interested in working on right now. Now this is very good for us in a lot of different ways. It consolidates and simplifies the architectural deployment system because everything will just be like one code base. That'll be really nice compared to what we have now. It's compatible with the open stack. It's open source, unlike our stuff we have right now, which is closed sourced Java code and Rails code. And dog food. I mean, we have a big investment in open stack. We should be using open stack for all the projects that we can. So that's one of the reasons we used to go down this route. Now let's do a quick demo. So you can see how the API works if I have internet connectivity. Looks like I still do. So I'm just going to cut and paste her real quick using curl so you can see how the API works. This is a doing a curl command against a, this is on a Rackspace public cloud server called NS, I called it NS1.RacksDNS.com. This is straight out of trunk of the GitHub, designate GitHub and configured. You can see it's actually responding. Now for these demos, I turned off the Keystone integration just so I don't have to deal with authentication tokens and stuff. That's an option you can use. As a Rackspace, we actually use something called the repose for our authentication stuff anyway. So right now I'm going to create a domain. You can see the curl command there. It's all in JSON. I'm including some data there that includes this domain. It responds back. It's created it, it gives me the ID. Now let's create some A records. And here I got to put in the ID of the domain that was just created. So you can watch me cut and paste, created that record. Let's create a CNAME. Again, make sure I'm getting the right ID here. Okay, so let's list the domain records. I give it, it's just doing a get against it with the ID. Make sure I get the domain ID and got the record ID. So that shows us our two records I just created with the address 127.0.0.1 for the A record for the root of the domain. And then I added a CNAME for the dub, dub, dub. If you just want to see the stuff for the SOA, you can just take off the records and I'll show you the TTL, serial, all the stuff that's in the SOA record. Now we can update. To an update, let's update the IP address. So for this one, I need the domain ID, do the records and record ID. The record ID, I'm updating the A records. So it's this guy right here, I need that ID. This is a lot easier if you use a winding library. But for the demo and just do curl. And it's updated. Now we can check that from outside. We can just look up on this server itself using host or dig or whatever. This is actually querying the power DNS server, which I'm using for this demo. And you can see it's update 192.168.1.2. The version two APIs going to change a few things instead of doing the puts and posts, we're going to be doing patch, which is the new way of doing REST API stuff. Yep. Yeah, it uses different DNS back in. So for this demo, it's just using power DNS. So what you're asking? Yeah. Yeah, the bind supports still a little rough at the moment and we're working on it right now. It works with what we have right now done, but we don't have it checked in and actually committed into the GitHub core yet. So we're still making some modifications. So I'm just doing the power DNS, which works pretty well. Then just to delete the whole thing, you can just send a delete command. And again, but in the domain ID. Again, if you've worked with the OpenStack APIs natively, it's very similar to the way everything works there. And it's gone. If I go back up to the top and just list the domains in this account, it's all gone. So that's a demo in a nutshell, the most basic features that you can get through the API. Let me go back into presentation mode. Okay, so that's pretty much why I head right here. We're looking for more people to help with this project right now. It's just HP and us we'd like to have more people involved in this helps our incubation status. This is where the you can get the information on the project. We have a pretty active IRC room on free note open stack DNS codes all in GitHub. And we have some pretty good docs, we've been working on docs, we got pretty nice getting started guide we had one of our interns work on. So also there's a blog article on the one of the rack space blogs that was just put up last week, I think. So any questions?