 Okay, the music has stopped. The time has come. Thank you all for coming today. I know it's the fourth day and people are probably thinking about going home, many of you have, but it's good to see you all here. So thank you for coming to this talk. Today's presentation is going to be on Moniker Managed DNS for OpenStack. My name is Patrick Galbraith. I'm from HP Cloud Services and I'm with the DNS as a service team. HP Cloud DNS is the official name. And I'm here to give this talk about Moniker. So a little bit about myself. I have been working with open source since about 1993. I was at andover.net slash.org for a number of years and worked in a number of companies like LICO, classmates, MySQL for three years, and now I'm with HP. And I always like open source projects and have been working with OpenStack now that I've been at HP. The first question we want to ask ourselves is it seems like a simple question. Why would I ask this question? What is DNS? Well, just by asking the question, you realize it's a bit of a rhetorical question, but how important DNS is and how fundamental DNS is to everything we do in our daily course of work and how the entire internet, everything works. It's the internet telephone book. You want to get to a particular site that the lookup gives you an IP address and your browser does the appropriate thing or whatever service you're using or whatever method of connecting SSHing. It knows how to get there. And likewise, if you're doing reverse lookups. I come from, as I mentioned, I work at MySQL and my background is databases. And I like databases. I find them really interesting to work on. And when approached with this project, I thought, well, this is a natural fit. It's a hugely distributed database that makes it possible for us to do what we need to do every day. It's also asynchronous. You make a change and whatever TTL value is set, that change is made. It's not going to happen right away. You know the rest and I don't have to spend too much time explaining that. But I wanted to underscore the importance of DNS. So the next question is, what is DNS as a service? Or more specifically, what is managed DNS? Well, if you can think of it as commoditizing managed DNS services. Normally and traditionally you would manage your own DNS server and have to update, manually update your bind files and administer that DNS server. Well, managed DNS means all that joy is taken away from you. And it's more of a service that you use and you don't have to worry about the specifics. You don't have to worry about what it is, the underlying DNS server. How does it work? I make a change. It's possible for people to do lookups and that change be reflected in those lookups. Providing DNS as a service would provide a restful API for management of DNS records and zones. Make your changes through that restful API, whether you're using some sort of web client, REST client, or doing it programmatically through some kind of bindings to that REST API. And of course this provides reduce complexity for end users of this service. It's easy for them to maintain their records. Anybody should be able to use it. So where and why would I use DNS as a service? Well, of course we want DNS services for our instances, but we really want DNS services for everything. Anything you're going to use, you're going to want some sort of DNS for that. And that's what this service would provide for you. It also allows you to control your own DNS. You're responsible for your DNS and you're not tied down to the specific details of how to maintain your DNS. You could focus on just that task and that's what the service provides for you. Also, I came from not only a database background, but I originally started out in the Perl world and I like to script things, try to make things, do as many things as possible and automate them. Now I've gone into Python and Ruby, scriptable updates and modifications to your DNS records and that's what this allows you to do. So, about this talk, what is moniker? Moniker is the thing we're talking about here. It's an OpenStack inspired DNS as a service project. And by OpenStack inspired, we mean we adhere to the conventions of OpenStack. We've designed moniker from ground up to work, speak, talk and do everything like any other OpenStack project would do. And also with in mind how would we integrate into OpenStack. It provides a DNS services from the entry point of creating update, maintaining and deleting DNS records using the moniker API. It also of course, depending on, you don't worry about these details, but it provides DNS resolution for your end users. Importantly, with the design of moniker, everything's very modular. Everything we've done, we've done in a way where just about everything can be configured primarily database backend or the DNS server you're using. We've also developed it with in mind to be integrated with other OpenStack components. And it's also an ideal project to use for building a DNS as a service if that's something you like to do or even if you wanna run your own DNS server. For us at HP, we've developed our DNS service using moniker, that's the core of that. Why moniker? You need DNS. Everybody needs DNS. DNS services, an API out of the box. It's a very easy service to set up. If you, depending on your needs, you just follow the installation and you know, presto, you have a DNS server to utilize whether it be for whatever you're running in your cloud or outside of the cloud even. Also, through the goodness of being an OpenStack inspired project, it utilizes Keystone for authentication. So whatever your authentication is for your other services, you obviously have that for moniker and can utilize that. Also, we've designed it in mind with basic interoperability with Nova and Quantum and more to come in that regard. Command line interface and Python bindings. Command line interface for those of you who don't, who like a nice standard CLI that works like any other OpenStack CLI. Then of course, programmatically you can utilize the RESTful API about the architecture. This provides an overview of what the architecture is for moniker and it'll start with the entry point with REST API calls to moniker API. That is then goes to a rabbit MQ, which is then picked up by moniker central, which is the only component within moniker that talks to the moniker database. So any changes that happen through the moniker API are picked up, acted upon in moniker central. The moniker DB. And then depending on whatever type of DNS back and you're using, whether it be power DNS or a file-based DNS system such as bind. For instance, if you're using something like power DNS, it's a database backed DNS server. So you make your changes through the database in one place and so that's where moniker central makes that change. If you're using a file-based system such as bind on each of those bind servers, you're going to be running the moniker agent which perceives its messages also from rabbit MQ from moniker central and makes those changes to the files for bind as well as reloading bind using something like R and DC whenever a change is made. There's also MySQL bind is another back end that we support and similar set up there. You make a change to the database as well as update some of the zone files. The overview for moniker. Moniker API, of course as I've said it's the API front-end based on Oslo-Wizgi as well as Flask. Moniker central, that's the core business logic and it's the only piece that talks to the database. Moniker agent, this is optional depending on whether you, as I said you run a file-based or a database back-ended. A DNS server, it's used to fan out the state changes to each of the DNS servers. Whether it updates the bind zone file or whatever it has to do. It does that on each of the DNS servers. Moniker sync, this is an optional entry point and I forgot to mention this back on this slide. This is where notifications would be received from either Nova or Quantum and those changes would be acted upon through moniker. So think about it this way, for instance you launched some instance and had a DNS entry for it. When you relinquish that instance and delete it you of course don't want a DNS record pointing to it so in order to do that functionality events from Nova would have to be consumed in order to make that change happen. Also, pluggable storage. We have an interface to the databases. Right now we have relational databases through SQL alchemy but it's for any back-end. And out of those relational databases with SQL alchemy we've been working with SQLite, MySQL but really any database that SQL alchemy worked with. Pluggable back-ends, interface to other DNS servers not just bind and power DNS. The idea is that you would develop your own interface depending on what kind of DNS server you're running, moniker has the architecture for you to be able to do that. There's also existing implement, as I mentioned there are existing implementations for power DNS bind nine and MySQL bind. Future developments, of course pool requests are greatly accepted. Tighter integration with Nova and Quantum as in the processing the events from those and making whatever appropriate changes to moniker. For those DNS sec, dev stack integration, horizon integration, and we want to apply for open-stack incubation, something we're going to be doing very soon. So I'll say thank you for listening to the presentation. The good part now comes with questions and of course for questions I leave these links up for you to be able to find all the resources for our project, IRC channel, where the code is and of course the docs. So I'd be glad to answer any questions you have. I think so. Yes, yes, yes, let's talk after this. Very good. I like that question. I hope your question is as good. Probably not and for all I know won't even make sense. I don't know DNS all that well. Okay, so what would need to change if anything at all or is it even possible to do support geo-location with this API? Well, that would be more, you know the core of moniker doesn't necessarily handle that particular aspect. That would be more of what your DNS provider has built into their services. Would you need to expose anything different in the API? Okay, cool, nice. Great work. Same thing with something like round robin as well. Okay, yeah. If that was also your question. I know it's not, I'm saying that, you know, it's a similar type requirement. Okay, integration with quantum over Z. No changes needed on the other side or is it just in the one? The changes would be, you know we would have to flesh out functionality for consuming those messages but I don't think there's really much on that side that has to happen as far as I know. Yeah, and it's standard. You know, we, like I said, everything's built with adhering to open stack standards and so, you know, it's well built for dealing with that. What's that? We'd also consume changes from the Nova DNS bindings as well. Those are only A records but the idea is to be able to act upon those as well. Before bindings. Yes. Is that not required anymore, right? I don't know. It's so huge for today who uses them and no one spoke up. So potentially on the chopping block, we would like to bring that over to quantum. Ryan was. Quantum joint session where we talked about it. No one spoke up so. If you guys want to do that, go speak up to, yeah it is. So good, it's not like that. Good thing I mentioned that. Yes. We do support those, yes. We will update that. If file based. You could do that. There's nothing preventing you from doing that but it's. Write your own plugin. What? Write your own plugin. Yeah. But for example to support dynamic DNS, if you want it to be complete, we'd have to write a new plugin. Just like power DNS, the power DNS implementation so we've worked with, we use MySQL replication to do that but you could use master slave replication of DNS to do that as well. It's, that's the nice thing about DNS is it's pretty, the sky's the limit on what you can do as far as how you haven't implemented. Yes, I think moniker could fill that role. If it has to do with DNS, it would definitely fulfill that role depending on whether they used it for that purpose. Moniker's whole purpose in life is DNS. However you utilize DNS within your organization or slash architecture then it's up to you. I don't know if that answered your question. We would like it to be used for that, yes. Yes, absolutely, yeah. Yes, well we're private data right now but we'll be going public beta and then we'll be going into general availability sometime this summer. And yeah, it's very usable. Yes, yes. Yeah, we have an importer, exporter for bind nine. That's something that can be developed as well. It's ultimately how you utilize the API and however you choose to parse records. We have one for bind but it could be done for anything depending on the record format. It's part of a tool that utilizes the API. Yeah, we're working out the performance issues of that. But as far as the API, it's not part of the API, it just utilizes it. You could do it a number of ways. You could go through the API and or you could go straight into the database. You know, if you're using a database back into DNS server. Yeah. API itself cannot parse all the data, right. That's to pass that to the... Some other hands out there for the hands go. Any other questions? Rise and support. Rise and support, yes, that's on our roadmap. It's something we want. It's a kind of funny question. We're talking to them but not in the type of talk you're thinking of. More technical issues where we partner with for HP Cloud DNS, we partner with Akamai and we have some internal systems that utilize Ultra DNS as well. But not quite yet but I'm sure we will be. Well, moniker provides you a means to set that. It doesn't do anything in particular with regard to that. So it's really ultimately how you have your DNS architected whether you were using moniker or whether you were using just a straight DNS server and managing it traditional way. And that, I don't know. It really depends on your architecture and your needs for DNS. Yeah, it's a global. Any other questions? Discussion, arguments, thoughts? Thank you very much for coming. I know it's late and I hope you guys have a great trip home.