 Hi, welcome to the Designate project update. My name is Graham Hayes. I'm a software engineer with SUSE on a member of Designate Core. I'm Tim Simmons. I'm a software engineer at DigitalOcean. Oh, I'm the Designate PTL. So just a quick overview of what Designate is. We're a fairly standard OpenStack style application. And we provide DNS services for OpenStack Clouds. We can be run without OpenStack, but we're mainly aimed at working within an OpenStack Cloud. So we have the usual scalable architecture. We have an API service, which talks to what we call Designate Central, which is a business logic, which talks to the database. And as part of how we interact with DNS servers, we have a scalable producer and workers that produce work and perform the work. Part of this means that we can support a wide range of DNS servers, from bind to paired DNS to services like Akamai or Dinect. And because we have the way we are architected, we can also support having multiple pools of servers. So the traditional example that we give is you have an internal zone internal pool, which is everything inside your data center and for things that aren't mission critical for R&D or for QA environments. And then you can have an external pool, which may be hosted on Akamai or Dinect. Or we also support federation between designated instances. So if you're a Designate, you could have two instances of Designate running. One which is managing critical things and one which is internal. And we allow federation between the two of them. So updates done on one can be reflected in the other. We have integrated pretty well into the OpenStack set of the projects. We have plugins in Neutron now that allow for automatic records to be created whenever you create a Neutron port or a floating IP. And this also has the advantage of managing reverse DNS for your users. We have the usual heat resources. And we have a horizon plugin. Trove actually can integrate with us directly and create DNS entries for your databases. And we support pushing information into Searchlight. So if you're using Searchlight to do searching across your OpenStack installation, you can push notifications from Designate towards Searchlight and it'll index the resources. We also have a Rally plugin for benchmarking the performance of your cloud and how your DNS services is running. We also have a special sync module which listens to notifications. We have a couple of example plugins there that do very basic whenever you create a Nova instance or Neutron port, it'll create a record. They're to serve as examples, but it allows you to have something that listens to the event queue. And whenever anything, so any project that emits events, you can perform an action in Designate. So if you wanted to have it listen to Magnum COE creation events, it could create DNS entries for Magnum just by writing a simple, it's a very simple plugin interface to create and update the records. We also have support in the Shade Python library. And when we got into Shade, the Ansible resources for Designate, so you can create zones and records directly from Ansible. And we're slowly but surely getting resources merged into Go for Cloud with the aim to get tools like Terraform to be able to create and update zones and records. So Designate's actually been around for a long time. The first public commit was in September of 2012. We ran in production in HP Public Cloud for two years until it's on timely demise. And this is all before we were actually incubated into OpenStack. We were previously running in Stackforge. Currently, in the last cycle, we had 46 contributors. But in a theme of this presentation, the numbers, that's not as good as numbers, you think that there's five people who did most of the work. There was a huge amount of people with single commits. And part of the update is that we need people to start contributing. So I'm not sure if you can see that, the exporting tool. You can't really get good exports out of the user survey data scientist tool. But we have 8% people in production and another 8% in testing and 37% of people who responded to the survey interested. As you'll see, we even beat out containers of people interested in us, which is something to be said these days. So there is definitely demand for designate. Users want it. Traditionally, in enterprises, anyone who's worked in enterprises has memories of trying to get things updated with service tickets. And it can take more than a week to get a record created or updated. So with designate, allowing users to have direct control allows them to cycle through. So if we let people create VMs at whim, we should allow them to point traffic to it as well. So we haven't had a great couple of cycles since Newton. For a little bit of history, designate was started by an Irish company called Managed IT in 2012. The person who founded designate was Kyle McGinnis, who was my co-founder of Managed IT. And then for a long time, during the ice ice through to Newton, there was a lot of funding from Hewlett Packard and Hewlett Packard Enterprise, Rockspace, and eBay. But unfortunately, there is not currently any funding available for developers. So as you'll see, when Tim starts running through the roadmap, we haven't committed to a lot because we don't know we can actually fulfill any of the obligations. So bear that in mind when you're looking at the roadmap. And if there's anything particularly you want us to do, let us know. And our response may be, if you want us to do something, we need a developer to do it. But at least give us feedback about what we should be doing. So, Tim. So I want to talk about what we're doing in Pyke and what we're looking at doing with the qualifier that Graham mentioned going forward over the next few cycles. But first, recognizing some stuff that's already happened in Pyke that I think is really important. We've had huge documentation improvements. And Alex, Doc's Ptl, if you're watching later, thank you. You're wonderful. She really helped us unify and simplify and make our documentation a lot more approachable for new folks. And that was a major problem for us. We kind of had corporate knowledge about just designate over a long period of time. And it was mostly in the heads of a few of us. And we didn't really write that down. So we've kind of started to do that now. It's also in the install guide, the open stack install guide. We have a plugin for that. We are introducing Periodic Sync for our new worker model. Just kind of a feature that didn't work so well before. But now it's going to work really great. And that's going to make sure that, in short, basically make sure that all DNS zones are kept up to date. If something were to go wrong in the DNS server out of band, designate would come along and fix that. We also turned off our old API of this cycle. And our recent re-architecture to make things simple and scalable for the future is now on by default. So going forward, that'll be kind of the only way for new people to get in, which is great. This is kind of the open stack branded release themes slides. But it kind of works. So a major focus for Pyke is resiliency. And that's kind of how I was talking about with that Periodic Sync feature, where if something were to go wrong on the DNS back end, your bind server, seg faults and delete some zones, I don't know. There's a lot of kind of failure scenarios there. Designate will go ahead and just fix that for you without any manual intervention, which is pretty dope. Additionally, having the worker model on. That's kind of a weird word that means nothing, but essentially think a re-architecture that makes designate more scalable and simple. Having that be kind of finished and be the default for the future is a focus and that kind of lends towards scalability. Going forward for Queens and kind of beyond user experience is a major thing we want to focus on. Making it as simple as possible for people who are not contributors to the project to onboard and for users to use the project is priority number one. And interoperability is the minor focus there because we want to make sure that we are casting a wide net in terms of people who want to integrate designate with other services. We want to make sure that that all works really good. So maybe some of these things that might help those goals would be improving the horizon dashboard so that it's really great. There's V2 panels that are pretty new and those are great. But we want to keep on iterating and get more stuff in there. Continuing to simplify contributor onboarding, so this is writing more docs, simplifying operations, things like that, and just generally reducing complexity. People don't have a lot of time, usually when they're looking at and evaluating these projects and we want to make it as easy as possible if people get up and running. Even going forward, even further to Rocky, to be honest with you, this is hard to think about right now, kind of that far in the future, but making designate manageable and continuing to kind of be fault tolerant and just be easy for people to use is a major focus. This is the main point here, though, is we need help. You are looking at a picture of the OpenStack PTG that recently happened. There's our team photo compared to the Neutron team photo, which we were next to in the architecture diagram in the keynote today. I don't know if you saw that, but it's a pretty similar picture today, but it's actually even more bleak because when this photo was taken, I was still full-time, mostly doing designate things. It was a nice tweet from Thierry, going retweet that like right now. I'm gonna give you a little picture over time of what the designate community used to look like. The first one on the left is Atlanta, and then we did a couple of mid-cycles in Ireland, and these were two pictures from there. And as you saw, the picture on the left is where we are now. So we have a small group. It's mostly kind of gramming myself as the kind of maintainers, and we've had some good contributions from NEC and recently Fujitsu, who have kind of come in and had specific things that they wanted to do, and kind of some general maintenance stuff that has been really welcome. But what's kind of important to stress here is that Graham and I are kind of the core, and neither one of us are doing this full-time. So it's harder for new contributors to come on and be like, okay, I contributed a thing, and okay, it's gonna take us a few days to review, and that's hard. And so we kind of need contributors to do a few things, but the first is maintain. So, you know, fixing OpenStack gates so that code can merge running meetings, triaging bugs, supporting folks who drive by on IRC, asking questions, ask.OpenStack.org, mailing lists, things like that. This is not an easy thing to do, but it's tractable, like you can become that. In terms of actually doing things, code-wise, squashing bugs, writing docs, new features, these would all be really welcome contributions, and there are people in this room, I know, that are saying, hey, I would love to use designate, but for X, why don't you do it? I don't know, come on in, we don't bite. And also for events like this, attending summits, and evangelizing, and you know, the fact that Graham and I are here today is a miracle of corporate, you know, just more wonderful generosity, and you know, going forward, there might need to be new people coming and giving this talk and giving other talks, and we had another talk on designate today, which was really awesome, but we're gonna need more. So if you or your company is out there, you know, wanting to have a greater involvement in OpenStack, which you don't know how, or you wanna become a leader in a project, or you know, be an important member of the OpenStack community, or maybe you just wanna make a difference out of the kindness of your warm little hearts, designate is for you, okay? Like seriously, like you're gonna walk into a neutron talk later, and be like, hey, I wanna get involved in neutron, it's gonna be hard, it's gonna be less hard to get involved in designate. Whether that is something that changes your mind, whatever. So I wanna give you a little example of kind of how this could work going forward and how this has worked. Our gates, which is the process, this is all the stuff that runs on any new code that is gonna be merged into designate or any OpenStack project, all the lights need to turn green before the code can be merged. They break, even though the actual designate code is probably not broken, roughly monthly. There's a lot of different reasons for this. Global requirements, tempest interfaces, DevStack grenade, bugs in our own code that gets surfaced via some other change. There's a lot of different ways this can change, and there's something to be said about both our code and for OpenStack in general as to why that happens so often, but that's probably another talk. Sometimes these fixes are simple. It's one line here, one line there, reverting a commit here, yelling at somebody here. Sometimes they're not simple. Sometimes they take significant time, days of diving in three layers deep into some weird event lit commit from eight weeks ago that you've gotta go and figure out why the thing broke and get something to change. It used to be that that wasn't really a problem because we had two dedicated Dev teams of people working on merging code and designate all the time. So when they broke, it was an emergent thing and we had to fix it right away. Now it's not so much like that and recently our gates were broken for over a month. So OpenStack cycle is six months, minus feature freeze, minus this and that. Like that's like a significant portion of the cycle where just nothing merged and nothing happened. That's bad, but I don't know. Like what are we gonna do? We didn't, my grandma or myself couldn't find the time to fix it and well, eventually it was fixed. There was some great work from some really awesome people, Diana Clark, Monty, Gwen Han-Kow and Jesse Pretorius from Rackspace and all these folks from all sorts of different places kind of came together and worked on little pieces and then we kind of like, oh, I think this is like this bit here, this kind of this dart that you threw. I think this is a good one. Eventually it took longer than you'd hope but like it's OpenStack y'all, that's what happens. We got it fixed, it wasn't a simple fix and we got stuff going again and kind of the wheels started turning again and things are good now. There is no reason that this process cannot be repeated for other things, right? So fixing the gates is one thing but that process was more complicated than fixing some of the bugs that we have open right now. People could go and do that. We have people almost every day, sometimes three, four, five, six a day coming drive by in IRC asking a random question, kind of requesting support or just having a general question. We usually answer them sometimes, like recently I answered a question that was like 18 hours old, don't know if that person ever got it, sorry. But if there could be other people to just come by, you don't have to have the whole answer. If you have some inkling of what might be happening, just spray it out there. Like there is literally no downside to trying to help somebody and failing. People who have new features that they wanna contribute, just do it man. It doesn't have to be perfect the first time, it's totally fine. People who are onboarding, there's operations things and document things that people could be fixing as they're going along and that would be really, really helpful to us. So if I'm a company going, why would I do this? There is things that you get out of this and being an important member of an open stack project means something, becoming leaders in the project means something and it's just not that hard. Putting in a little bit of time and a little bit of money, I think, from a company perspective could really kind of reap the rewards and anyone can do this. It doesn't, you don't have to be a software engineer. It could be docs, it could be ops, it could be tests, it could be just a user going, hey, I tried, I failed. What happened? And that report helps somehow. Designate is not a super hard project to get involved in, it has its complex bits but it is not Nova Neutron or something kind of katulu-like and it's complexity and that is something that I don't think is obvious to some people. So now that you're all super inspired to help, just go right now and start doing stuff. Fixing bugs, there's a tag and launch pad called low hanging fruit that has like nine or 10 things in there that I think would be a really good first place for people to get started. If you can't find that, whatever. Open stack DNS, hash of a tag DNS on FreeNode, mailing list, Mugsy on Twitter, whatever. Getting contact with us. If you just boot up and try and run the project and read the docs and find that you fail somehow and then you figure it out, write a docs fix or write a whatever fix to say like, hey, this is what I needed to do to get up and running or when we tell you, hey, it was a simple thing. We answered your question or somebody answered your question in IRC, add that to the docs so that the next person that comes by doesn't have to get stuck. But honestly, right now, something that you could all do is after this talk, come up here and talk to us and tell us why you're interested or why you're not interested or what it is that we could do or just what the situation is to get you going on board because time is of the essence, right? Graham and I are doing this mostly in our free time because we care about it and we wanna see it continue and go forward but we're not gonna be able to keep coming and doing this talk, maybe. We don't know for sure. So come and talk to us. I mean, it doesn't even matter. Just tell me something. And if you don't wanna talk to us right now, spam the mailing list, hit us in IRC. Just literally, please come and talk to me. Don't just walk out of the room, all right? All right, just soak this in for a moment. You'll be, I know you're super inspired. Okay. Yes, one more time. Come and talk to us. Literally, any questions, big or small, any size at all, any, you know, if there's something that's like, oh, hey, I wanna know if Designate does this or I know Designate doesn't do this and I wanna use it but it just doesn't come and tell us and we can work something out. And if you wanna kind of dive a little deeper, we're having a project onboarding session on Thursday at 11 a.m. in room 105. So come by with your new questions. I'm sure there'll be lots of folks there trying to kind of get up and running. Seriously, come and talk to us. Or now or whenever, I don't care. And let's do questions. All right. Yeah, do it. Yeah, so in our docs, there's a, oh sorry, the question was, let me make sure this is clear. Is there kind of a list of vendors or DNS servers that Designate supports and kind of a matrix of what the level is? Yeah, so in our documentation, they're right up on top. There's a DNS server driver support matrix that tells you all the servers we support and kind of what the various levels are. I just think it's missing. Our interface to DNS servers is very, very simple. Yep. Yeah, it's really simple. We're nowhere near as complex as like Nova or Cinder or Neutron for the interface to other two vendors providers. We have an Infoblox plugin. I will qualify that with a, it's limited. Okay. But there's an Infoblox one in place already. Sure. So Designate allows as one of kind of what we're talking about backend drivers, DNS server drivers, Designate implements has one of them for Designate itself. So you might have, and that combined with Designate's idea of server pools kind of allows you to have different discrete pools of DNS zones. So you could set up a, for lack of a better word, Master Designate and two more below that or DNS servers in one pool and another instance of Designate in another pool and you can create zones in the kind of master Designate and say, hey, push these crap zones like company labs, internal, whatever into the internal pool and push the official stuff like mycompany.com into a pool that talks to Dyn or Akamai or something like that. So that you're not, the only thing that you're managing is the, you get an API to change records and zone things like that but you can push the actual serving of the DNS zone out itself to a vendor while keeping a small DNS server running internally that's just for internal zones for your labs or whatever. Did that answer your question? Just use Master. So another thing that we didn't mention, Master, use the latest release. So Designate doesn't, the idea that you need to upgrade Designate at the same, have Designate at the same release point as all the other OpenStack projects in your cloud don't bother, like it doesn't matter. Designate integrates with Keystone and there are, if you're gonna do other things for, you know, try and use the Nova and Neutron integration and stuff like that, you're gonna wanna be kind of metaka forward. Just the V2 API, so. Oh yeah, that's true. Well, you need to be metaka of Newton or Neutron and stuff, but going forward. Basically anything post Liberty. Yeah, but the later the better. Yeah. You mentioned Keystone. Yeah, we had to. It was HP Public Cloud back in the day had a very unique implementation at Keystone that had something similar, so it's been there since the beginning. We also have some of the other standard features like quotas implemented and whenever we get around to putting quotas into Keystone, we'll support that as well. If periodic sync worked previously and as part of the rearchitecture to the more scalable layout, it was broken in that architecture. So if you're running the old architecture, it still works. You can. I will preface it with, it could be slow and depending, it all comes down to scale. If you're talking about a couple of hundred, even a couple of thousand zones, it's probably gonna be fine. It's when you get into large scale. Our test bases were particularly large scale when we were in public clouds, but for smaller installs, yeah, it's fine. Depending on your DNS server, it's not as hard to reseed. Bind and Power DNS are both relatively simple to kind of spin up a new server with a snapshot of the old one. If it's Power DNS, do a database dump. If it's bind, pull your zone files, whatever. That will be quicker, because periodic sync, again, runs in a period and it's also, it runs with shards. So it's designed not to take down and designate because one of your servers fell over. But you could configure it to go quickly. It's a few configuration file changes and it would happen right away. I think it happens right away when, oh, do you have a question? You do, though. Any other questions? If you go back one slide. Oh, yeah, so for kind of a more in-depth discussion about kind of the sad bits that I talked about, you can QR that and or go to that link. You can also just... That's the old. Go to... The screen's frozen on the wrong slide. Oh, good. Go to gram.haze.ie. It's like the second blog post now. That's a much larger detail right up of how we got to... Yes. Of how we got to from a lot of contributors down to very few. So we still have time. Who here actually has deployed designate? Who here is interested in deploying it? Is there anything blocking people who are interested? I hope so. We can run... No. That's why I just didn't... Still didn't get to actually putting it on there. I won't do it because it would be a nice to have. Yeah. So that is... Okay, that makes sense. In my case, I think the info box plugin's not good enough. You wanted the advanced policy-based naming and stuff? I don't know what we're going to do. Okay. To get you over to our priority and us back in. I think I'm going to do that. And it works really good. I've heard of a lot of people also delegating cloud.something to the... We have our delegation. And then within designate, you have those policy controls on the pattern names. You can set that there has to be a TLD. And then they just set the TLD as that domain. And it works. Traditionally, it's been... Once you actually get it up and running, it's relatively stable with the caveat that distributed systems are hard and do fall over from time to time. Maybe that's our problem. Yeah. Yeah. The integration is pretty simple. You know, it's in terms of like, oh, what would you have to do to get access to their stuff? You know, it's be a firewall rule change. But yeah, a lot of... Create me a database user or whatever. Internal DNS teams don't like hunting out control. Yeah, that's true. Yeah. Okay. If there's any, no more questions? Call it. Come and talk to us afterwards. Yeah, we're around. We're around. I'll be wearing the luminous green t-shirt that I was hunting to do. All right, thanks. Thanks.