 Want to kick us off? Sure. Hello, welcome. Hope you're having a great conference. Hope you're here for the what's cooking. This is a deployment with the chef and the open stack cookbooks. So I hope you hear about that. Everybody can hear us all right. It's all good. OK. We'll start off with some introductions. Hi, my name is JJ. I'm that guy. I'm a senior partner engineer at Chef. I am the open stack chef guy. Anything chef-related and open stack-related usually gets funneled through me at some point. Technical resource. So my name is Mark van der Wiel. I'm from IBM. We started using Chef a few years ago when we got involved with the open stack project. They seemed like a good pair to put together. So I've been working on the project for quite a while now and I'm one of the course. So what is Chef? If you don't know, it's an application to be able to provision and control your machines from a centralized repository. It's infrastructure as code. Everyone know what Chef is, so I can just kind of know, yes. So as it says, some of the simple concepts are it uses idempotency and also you'd have state-driven code to be able to make things happen. So you can say, yes, I would like to do package VIM and you run to the Chef client and installs VIM for you. And it uses, as I said, infrastructure as code where you can control things called cookbooks that I'm going really off the topic here. So as you can read, it automates and how applications are configured, deployed, managed across your network, no matter the size. The advantage Chef has over a lot of other configuration management systems is that the Chef client is run on the compute node instead of on a centralized server. So you don't need to expand your master of puppets, if you will, to be able to take a blob back and forth on the machine. So I'll get into what do you get with the current where we're at with this project. This is part of the Big Tent. Everybody knows the Big Tent, right? It's the core projects and everything outside the core projects as part of the Big Tent. The OpenStack Chef cookbooks are in the Big Tent. So you can take a look at them where we participate in the community like everything else. So what do you get with it? The thing with this project that was key to making it whole was, of course, coverage of at least those core projects in OpenStack, Nova, Glantz, Sender, Keystone, all the rest of them, right? So having support for those so you can lay down OpenStack with that type of deployment was the goal of this main start of this project. The other part about this is keeping the overhead down on your nodes, right? So you don't want to have a lot of infrastructure on your nodes to be able to have to manage these nodes. So these nodes are managed via Chef, and it's ChefClient is called. That's an agent that runs on the nodes. The biggest thing that I think that's most important if you leave this room out of anything else is to understand what distinguishes a lot of the Chef design concepts. I'm a designer. I'm a coder, right? I keep designs in my head more than I keep ads in my head of other things. Is the idea of being state driven, OK? This means you run something, right? You run it again, and you run it again. Every time you run it, the state will be the same. It's hard for people to grasp that because most people don't code that way. That's not how code is written. That's not how scripts are written. Scripts are written. You run the script. It doesn't work if I run it twice. Oh, you can't run it twice without deleting this first. That kind of thing. All the backlash you have with running things more than once. The whole point of this is trying to be a state driven for your node management. And of course, the other thing about it is that the community has come a long ways with our cooperation with getting into the big tent, as well as moving along with our testing. So we think we've done a pretty good job moving the unit tests forward with these cookbooks so that they're relatively stable. And I can add to that also. Chef is Ruby. It's not Python. That was Freudian. So we have TDD, our test driven development, built in. If you ever use any bit of Ruby at all, one of the tenants of Ruby is test driven development. So we have unit tests. And they are actually RB files. So you can run actual RSpec, or we call ChefSpec, which is a level on top of it, of RSpec to be able to verify that when a converge happens, which is what a Chef client does, it comes out as a state you expect to have. So you can create a CDCI pipeline using the testing. So when you're moving through your changes, i.e. creating an open stack cluster, you can actually, before even running it on a physical box or a VM, you can verify that the thing will come out how you expect it to come out, which gives you confidence in your changes to production, because it'll catch early on in the pipeline. So the next thing is, OK, why would you step up to this versus other types of deployment mechanisms? And the one like you mentioned before is the part of this infrastructure and being tested before you move it. The cookbooks have resiliency in them that drive your state driven deployment of your open stack clusters. The other thing is that I think it's a good and bad thing, and you'll see it later in the slides, is customization. This is a fully customized solution. You can extend it, beat on it, twist it, turn it, and it does have the ability to be conformed to what you really want. And that leads to the last one, that it's customization, but it's beyond customization of what open stack wants. You can customize it also with how Chef works. Chef allows itself to be easily expandable and wrapped, if you will, with other solutions that can go with it. So it's not only customizing what you do in your cluster, but also customizing your management solution. So that's some other things don't quite do that much for you. Talk about our community? Yeah, absolutely. So one of the strongest things Chef has is we have a huge community online to do, to create what are called cookbooks that are literally a collection of recipes to do something. Anything ranging from building an open stack cluster to installing Vim to controlling SystemD and everything between. There's something called the supermarket, which is supermarket.chef.io, which is not on that slide. I should have put that there, which is a collection of places for cookbooks. So if you have your laptop in front of you, you'd probably want to check it out. It's a great way to share cookbooks and have things out there. So with the cookbook community, we have volunteers controlling the cookbooks and administering them. And there's a certain level of, you can have gradients of quality of cookbooks, but most of them are that are out there do what they say, which is amazing. And it's all completely volunteer driven, so which is great. Oh, and we should say that too. Because yeah, we are part of the big tent. We do get ATC. I have verified that. So if you do commit to our cookbooks, which, as part of the open stack community, you can go through the normal Garrett process, and you will get a great ATC. So here's a slide that's trying to tell you the nuts and bolts here about there are good things and there are bad things, strengths and weaknesses. So one of the strengths that I think is one of our most important goals we've been trying to focus on is being production ready. So we have the test cases behind to verify that we can actually use this in a production environment. Speaking as an IBMer, we have used this in three products already. It's shipping. It's out the door. It's in the community. We've shipped it to hundreds of thousands of customers already. Underneath the covers of customers don't even know that it's being used, the chef serving clients under the covers being used by our clients. Hundreds of thousands? Whole bunch of them. Oh, OK. So the instances of the customers are there. And then like I mentioned before, in order for IBM to do that, we had to extend it with our own IBM wrappers, because we have some things that we do slightly differently, but we were able to do that with these customization with the wrappers. And of course, the platform dependencies was key for us, because we decided to use Red Hat for our enterprise solution for the platform of choice for the internals of our products. And we were able to do that. These cookbooks support not only the Ubuntu and the conical side, it also supports the Red Hat side, which is very important. And some Sousa's still in there. Sousa, if you've got Sousa's expertise, we'd love to talk to you. Yes, we would. And of course, you mentioned the supermarket cookbooks. Third-party cookbooks are essential, right? So we don't develop the Apache cookbook. We don't install Apache. There's a cookbook that does it for us. That's out in the community, right? We don't do some of the database, MySQL. There's a cookbook for MySQL. That's used by part of the OpenStack cookbooks to give you the total solution. And of course, like I said, the community strength. We've been doing a pretty good job, becoming part of the big tent, and moving our community forward. As for wheat mixes, we still believe that our cookbooks are too complex for most folks. It takes them a while to bring themselves up to speed to understand the concepts. Not that they're hard. It's just we have a lot of pieces in place. It's kind of like a puzzle. You can put it together. You will see the picture when you're done. But there are a lot of pieces. And can I interject something real fast? We have our PTO. We have a new PTO. John, come on up here. He wanted to talk about the complexity and what we've decided to do for this next release. Yeah, hi. Yeah, especially for these weaknesses. The complexity is, I think that's one of the biggest problems. So as Mark and JJ already said, it's easy to add something like wrap cookbooks, add a lot of community cookbooks, add another layer to that via environments, roles, whatever. So you can really easily customize what you're doing there. And we did that for some years now, which in the end, right now, put us in a place where we really have a lot of layers, where you can configure everything. But that makes the whole thing very, very hard to understand. And although it basically has a lot of switch cases for all the platforms, you can deploy RedEd and SUSE. And you can use MySQL and Postgres and DB2. You can do the most, the craziest things with it. But it's hard to understand. And we want to really bring that down to covering the most cases, or this idea of covering 80% of the cases, but just 20% of the code. So really putting out all of that stuff that is not needed by most of the customers and moving that to somewhere else. We're still talking about that. Tomorrow we have a session where we will talk again about that. But we really want to make it easier to use these cookbooks and to throw out a lot of code. Thanks, John. Thanks, John. Yeah, and the bottom one on there, of course, like you mentioned before, is this is Ruby code. So obviously, if you don't know Ruby, but for me, I've coded in how many different languages, right? To pick up another language is not that big a deal. So if that's your stumbling block, then I think you've got other things to worry about. The other part that I put on there is individual projects. The cookbooks is not one project. Like the rest of the cookbooks, there's Nova and there's Nova. No, for the cookbooks, there's a separate project for every corresponding project in OpenStack. So there's a Nova cookbook and a Cinder cookbook and so on. So that also tends to lead to a little more confusion because you have to manage more projects. Yes. So this one right here, I figured I would bring up pretty early on in the conversation. Because a lot of people wonder, so why not use Ansible? Why would you use Chef? Well, not only as a Chef employee, but as a community member of our community. I believe Chef is a superior product for this. Because if you've ever tried to do an if statement instead of a YAML file, I want to meet you and buy you a beer. Because I haven't been able to figure it out. The way the tasks are run inside of Ansible and the playbooks that are run, it's not idempotent. You can't rerun it. You can't verify the machine is in the state you want it to be in. Chef, it's all built in. The Chef, you can actually, as Mark was saying earlier, it's idempotent. You can run the Chef client as many times as you want to get the desired state. Ansible, you can't do that. Ansible, you run once, and then you hope that the compute node pops up inside of your cluster. Could they continue on that flame more here? Yes, exactly. So why not Puppet? Have you looked at the Puppet manifest recently? So even Infra, as of this summit, is talking about using masterless Puppet to do their deployments. So the major thing, it is literally called a Puppet master where everything stays. And it's gotten so large for Infra that they can't run it on a Puppet master anymore because all the compute happens on the Puppet master. Unlike Chef, which I said earlier, where the compute is actually done locally on the box, that it's going to be told to do the thing. So it's a scaling problem. There with Chef, you can do thousands and thousands of nodes, but there's a point in Puppet where your Puppet master will fall over, and then you have to build an infrastructure around your Puppet master. All of a sudden, you have three or four boxes as a Puppet master. The Chef server is just, in essence, a S3 endpoint where it pulls down, makes sure it's in the state that it needs, and then converges everything locally. I'm sure we'll have questions on those two for you later. Oh, I bet so. So keep those in mind. So let me go into a little bit of the details of how this thing kind of works when you actually run it. So there's the notion of a Chef server. And the Chef server, like you said, is basically an S3 point. It's basically your data point for all the information that the Chef client would need, which would include cookbooks, things we call environments that describe your topology, things that the roles that describe what's within your topology. I have a database server. I have a compute server. I have a network server. And then you have data bags, or basically containers of low-level bits of information, like how are you going to set up your user at Eastern Passwords? Are they going to be just floating around on the clear in some script file somewhere? No. You want it to be under control somewhere and gather together so you have all your essential information at the server level. The client is basically then just a user of that information to set up, to move your client, your node into the state you described up above. So if it's supposed to be a network client, it has a network role. It runs the network role with the recipes behind that. And boom, you get a network client. Underneath the covers, there are some other pieces that the Chef client uses. And one is OHI. OHI is another really cool thing I think that distinguishes Chef and how we do things differently than other folks is that it discovers the basic information about your node. Where I see other clients, they have to go out there and do this manually, or have other scripts to do it. OHI will know some of the basic informations about the node, the IP address, how much memory it has, how many CPUs it has. All these little pieces of good information are pulled right automatically into your Chef client infrastructure. So it's kind of nice to have it there, because then you can base your recipes off of that. And I'll talk one more here. And then I'll turn it back to you on the other one. So we basically have this. This is the projects that are out there today. So we have something called the Chef repo. It's our gathering point to bring all the cookbooks together. Like I mentioned, we have separate projects. Those projects are called cookbook, open stack, common is a common one that we have that kind of put some common code together. And then cookbook, open stack, nova, computer, whatever the rest of it might be. These are specific to those particular ones. And then of course, we have some other cookbooks we bring in. We have some wrapper cookbooks just in our own implementation to wrap around the database, or wrap around the messaging server. Because we don't know what messenger server you might want to have. Do you want rabbit, or do you want something else? The database, do you want MySQL? Do you want ProScratch? What do you want? We don't want to hard code that in our cookbooks anywhere. So we've wrapper the community cookbooks that support those with our own wrapper cookbook. So you can kind of see this hierarchical thing trying to form in your head, right? We have the repo, we have all the project cookbooks, and then we have some specific cookbooks that wrap even community cookbooks. So it's quite the scheme of how this works, but it comes together with the repo. So the open stack Chef repo is the thing that if you have any interest at all in this, this is where I'd probably like you to start. This is an all in one blob of the data you need to build an open stack cluster on your laptop. So if you have ideally 16 gigs, but you can get away with eight, vagrant and virtual box, you can actually, we have rake tasks and documentation on how to build with using the community cookbooks on your local machine a open stack cluster. It can be all in one, or it can be multi-node. So you can have multiple compute nodes after it with a controller with the network node inside of it. It even has neutron support also. If you're in essence, it's Chef Stack, right? It's Dev Stack running with Chef. And it uses right now the packaging from upstream. We haven't done it from source yet, but we are thinking about going down that path. The second bullet point is also important. Basically, there's a lot of people out there who want to just have an all in one build so they have an extra desktop sitting beside their computer or they've depreciated value in their desktop and they're getting a new one. But they still have 16 gigs. Well, we have documentation called all in one bare metal.md inside the Chef repo that will actually teach you from absolutely nothing to having an all in one build of Kilo right now from the ground up. So you can teach you how to use Hosted Chef and all the major portions of the Chef ecosystem. So you can actually see it. We're planning on adding multi-compute to it also. So you can horizontally scale out with multiple compute nodes. And then also, off of that, I'm planning on writing some documentation on how to teach you how to use the Cookbook Test Kitchen, which is part of the Chef ecosystem with that compute, with that Open Stack Cloud that you build. So some nuts and bolts here about how this kind of works. So the first thing is, well, if you're a developer and you want to get started, what do you want to do? The first thing, right, check out the Chef repo. That project is the umbrella project that brings all this together. What do you need on your laptop to get this thing going? The cool thing about this, but I think is another thing that I can debate Python Ruby. You can do that all night. That's fine. I'll have beers with you if you want to talk about it. I think it's great. It's a great conversation. There is this great new thing that they came up with that Chef that's called the Chef DK. It's a development kit that encompasses more than just Chef stuff, right? It puts Ruby inside there. And some other tools inside there. So basically, if you install the DK, you've got all the things you need. You don't have to go searching around and try to figure out what other packages you might need to install. They're right there. And in Ruby, they call them gems, by the way. Can I just jump in real quick? Yep. And with the Chef DK, it actually, for instance, on a Mac or a Linux box, it installs it under Opt. So it doesn't mess with your system Ruby. It has its own embedded version of Ruby and everything. So it's its own entity. So you don't have to worry about dealing with gem files you may have heard back in the day of Chef or whatever. It's all self-contained. Right. So that's a big key. You can start it right now, and it's not going to blow up your laptop or anything like that. It's pretty straightforward stuff. And then, of course, I mentioned like Linux Windows Mac is all there for this to get your development started, whatever you choose. The other part that we've been working on really hard in the last couple of releases is testing. Testing is done with make files. This is a Ruby make file that runs. We have our standard tests, like almost all the other projects have, some type of a lintest style test. And of course, we're working really hard to get unit tests fully complete. We've got quite a bit of unit test coverage right now. The big thing we've added lately is integration testing. So we're actually eating our own dog food here. We're making sure that when we run the tests, it's running against the actual stack that we put up there. We call Chef Stack. So what we're doing there is we're actually staying up our own all in one inside infra as a gate, and then checking to make the basic things work with temp business like that, run some basic tests, make sure things are up and running. So that's been a big thing. It's kind of cool that now we're actually, we've got gates that are running like the other folks in infra. You'll see everybody else is running Dev Stack to set up their open stack and then run a test against that. Well, that obviously defeats the purpose of using Chef to do this. So we're setting up our own stack in the gates, but Chef Stack. So that's clear. But that's what we're doing. And that was a big leap forward. So we're taking care of making sure that when things change, we're testing it, at least for the first part, for the all in one. Just to continue on with that, we did this just recently over this last cycle. We started this in Vancouver, and we were joking about it at Vancouver, saying, oh, this is probably going to take us a whole cycle to do it. But as soon as we sat down with the infra team, we discovered that it was literally just us hooking some things up. And all of a sudden, we're able to build everything we want locally. And this is important, because any change that you put into the cookbooks, any attribute change, anything you do, we have a non-voting job that makes sure everything it verifies. And then we even, as we say, run Tempest after it. So we actually verify that the machine, the OpenStack Cloud you just built and made the changes for, Tempest passes. Granted, we need to better Tempest tests, but we'll have that sales pitch in a little bit. So there's some other related products that GED is the owner of. So I'll let you know about those real quick. These are the three main integrations from the Chef ecosystem into OpenStack. So instead of the builders of OpenStack, consumers of OpenStack, we have a knife plug-in, which is Knife OpenStack, which basically is the major, I want to spin up a machine inside of my OpenStack Cloud. We have Kitchen OpenStack, which allows you to use the kitchen driver, which Test Kitchen is the integration testing framework for Chef to be able to spin up multiple machines or one machine inside of your OpenStack Cloud to make sure that it shows up how you expect it to. And then we have Chef Provisioning Fog, which is a little bit more, it's a resource to be able to declare clusters and multiple machines inside of your OpenStack Cloud. So if you want to spin up three machines and make sure that three machines are always there, you can write using Chef Provisioning Fog to make sure it shows up how it does. You haven't seen Chef Provisioning. Check it out. It's pretty cool. So just some references here that, like the other projects, we have a wiki that we've been trying to update and keep the documentation there for the basic development, how to get started, how to contribute, how to help out. We have meetings, of course, they're right there. We have an IRC channel come and talk to us. And of course, we are on Launchpad like the rest of the projects. All of the projects underneath I mentioned before, the repo, all the specific cookbooks, are underneath one Launchpad group called OpenStack.Chef. So now we'd like to leave time here, so you guys can ask your questions about where we're at and where we're going. We'd like to have a conversation because there's a lot of people out there that believe that Chef is extremely complex and challenging to use. And we'd like to have an open discussion about it, see what we can do better, or maybe stumbling blocks or anything. Anything? Paulo, I'm looking at you, buddy. No, go ahead, Matt. What is the coverage for the various OpenStack projects? I mean, do you have Heat, Morano, all those other things? That's actually a great question. We probably should have put that in the slide. So we have all the main core projects. And this release, I'm planning on getting Magnum and, was it Manila, I decided? Or was it something else? I think it was Manila. Manila. Those two projects. But all the core main projects, you can totally build off the ground. And that includes Heat. And the Heat was? It's not part of the circle. They're short on their maps. They moved, Heat moved outside. But Heat is already there. Orchestration is there. And then, Ironic, Bare Metal is there. Boo. So we have those there. And we also have some Docker integrations parts there, too. So those other pieces are already there. And then there's starts for cookbooks for both Trove and Sahara. They're started, but they're definitely not complete yet. So that's, if you're really interested in those, let us know. We can help you work on them. I don't think it would take that much to flush those out. It's just that it's not been our priority at the moment. We are trying to make the priority as Jan was saying during this next cycle is to make this more accessible to more people. We acknowledge that these things are complex. And we are trying to make it more accessible to more people so they can just build an open stack cloud how they would like to build. There was a question back here. I'll just leave this out here. Sorry, I joined a little bit later. But we are using in my company, I'm working for a German telecom. We are using a lot of Chef. And the main problem we have is how to package the cookbooks, how to manage the life cycle of the cookbooks to get them through a development or QA pre-production, production environment. And to guarantee that the cookbooks that were used in one phase, we are the same in the next phase. How do you manage this? So there's a handful of different ways. Off the top of my head, there's just simple version and pinning to make sure you're adamant about your version pinning. There's also policy files, which is another option, which we don't fully support inside of the open stack Chef project. But I can take that conversation offline with you. But when it comes to open stack Chef, the version pinning is how we do our things. Master right now, we don't version, because we're constantly moving it forward. But as soon as we stamp something as stable, QO, stable, whatever, then we have a very strict sumver policy that we actually put inside our wiki to tell you to make sure that you get exactly what you expect to have. So we take version pinning quite seriously. Yeah, for the IBM project that we worked on, we did it a couple of different ways. But the main way we had it is we basically had our own copy of the repo. And we had our own locking mechanism there to lock to the commit levels, in addition to just the version levels of each cookbook for every branch of the product. Yes, that means you have quite a bit of branching going on. But none of those branches, though, were forks. They were just branches pointing to something in the community. So that was the key, is that we weren't forking anything. We were just keeping track of, OK, we shipped out a patch and it used that set of cookbooks, and we could track it that way. And then on the internal side, we could use that as a tracking mechanism to fuller understand when something goes wrong, people can bring down the exact set of code again and take care of business. If you want to know more about that, I can talk you offline about that, too. OK, one of the traditional drawbacks used to be the complexity of installing the workstation, in addition to the server and bootstrapping the nodes. So what's the difference between the old Chef binary, the old workstation package, and the new ChefDK one? What exactly does it make simpler? Absolutely. So the ChefDK is, if you actually go to the old workstation wiki page, which we're not still out there, which we need to fix, the ChefDK is everything you need in that workstation as one binary. So it has all the testing, all the Ruby, everything locally there that you need. So the workstation, in essence, is just an install of that. It makes life much easier and allows you to get everything you need to get off the ground as quickly as possible. The key management can be answered in two different ways. If you're running off of hosted, there's actually a Getting Started button now that gives you all your key management you need and even creates a validation key for you. But if you're doing local or doing an on-premise Chef server, you'd actually use the same process because hosted and the on-premise server are the same thing now. Yeah, just to iterate, too, that what happens during our integration test, right, is integration step one, load and install ChefDK, step two, run the test. I mean, that's all it is. We don't have to worry about whatever else is on the machine. Just run ChefDK install, and then we start running our test. That's as simple as it is. So it makes it very nice. Though that's right, yes. And in 12.1 of Chef, you don't need a validator pen because it uses a user name to validate against it now. And you can see some examples in our repo about how we put together some of the data bags and how we're using the keys just in there. It's a way to get started. They all in one build, all in one bare metal build that is inside the Chef repo. I challenge everyone to go take a look at it and attempt to try it. I've had multiple people go through it and be extremely successful with it. All you need is a desktop or a machine that you're not using, and you'll be able to build your own OpenStack Cloud in about 45 minutes with all the configurations. And then as soon as you understand it all, you can actually blow it away, start over again, and you'll have it in less than 10. So less than 10 minutes, you can have an OpenStack Cloud running QA right now. We'll have Liberty soon. We're in the process of doing that to get it stamped where we're gated by the distributions and then the packaging. So that's why we're always trailing a little bit behind, because we're not doing it from source. We're doing it from the packages. But still, we try to stay as close to that as possible. But yes, I do challenge everyone to try to build, to the AIO bare metal build. Other questions? Yeah, I'll just start on the summary here then if you have something to let us know. But the basic we're talking about here is a project that has been growing. And we're learning from our mistakes. And we're growing. I think we're getting in a better way. I said, it grew in such an enough way that even IBM picked it up and said, this is to the point where it can be used in production for a customer. And we actually did that. And so there weren't, it wasn't perfect, but it worked. And it's been, it was quite a good story, I think. Especially since, like I mentioned, that a lot of folks I've seen there are forking the Copics internally. They want to mess with it and mess with it. And boy, I put my foot down really hard to say, in IBM, we are not going to, because we, that was our first attempt at the first team who started at IBM that did some of the chefs up. They forked all the cookbooks. And they were off in La La Land, masking changes. And I'm like, well, what good is that if you haven't worked with the community on making it better? So I put a stop to that. And it worked really well because now I became core to make it better. So I had to work my butt off to do it, but it was awesome. So, and that brings me to the growing community part. That we're always looking for feedback, good or bad, on the cookbooks, any solutions or any questions you have, we'd like to, a challenge is always good for me. And like I said, I think we have a pretty good future. As Jan, our new great PTL, we got going here, we are going to try to address the complexity issue with how the cookbooks work. That shouldn't scare you away. I mean, complexity is the thing we see with a lot of things. But I think, and I think you will see an evolution happen with how we address these things in cookbooks. We're going to take a different approach to how we look at the cookbooks in terms of trying to solve a configuration for everybody, try to make a configuration for the 80% of the users, and then other folks can add on what they want as they need. But don't let that complexity drive the main branch. And that's been tough because the history of these cookbooks came from a spot where they were trying to solve everything for everybody almost. DB2 support. And then, yeah, that's my bed. Sorry, I'll take that right on the chest there. That's DB2. If you're a DB2 guy, let me know. I'd like to talk to you. But no, DB2 is not part of the issue anymore. It's magically going to disappear from this particular project. And just to pair what Mark is saying, we are looking for more people to be involved. Our community is agile. The advantage of being small right now is that we have a core group of people supporting this. And we like working together and pairing and making things happen. We would like more people to be involved. And also, feedback. We desperately, desperately need more feedback. We know we're building stuff. We know people are using it. People just aren't telling it that it's broken or telling this it's successful. We need any type of feedback. We are on the official mailing list. We have bug reports. And my job is to make sure that the stuff is and I am the open stack chef guy, right? I am supposed to help make it forward. And with Jan now taking the PTL, we can move things forward. And I guarantee you, if you put up a patch, I'll be the first one to negative one it. It's true. This guy, he's brutal. That should thrill you, right? Because you're going to get that feedback. I'm pretty good at giving negative ones out right away, just to introduce you to the community and say, great job. And fix that typo. And maybe I spelled it wrong. So it's all good to get the bloods on. He's legitimately made me abandon multiple patches because I just couldn't do it. Sorry, I have one more question. You said that you use it in production right now. Are you handling the hardening of the hypervisors with the Chef cookbooks? There's the system level hardening. Yeah, probably I can answer that, especially for the telecom because we have also worked with. You're great. Yeah, we have also done that. The telecom laboratories actually in Germany especially have done a lot of cookbooks. And we are using actually the official OpenStack cookbooks with these hardening cookbooks. So it works perfectly. You are using the hardening of the .io from telecom. So it's basically just another layer wrapping everything, including the hardening, works perfectly. And the only feedback, and I know this sounds weird to say out loud, but the only feedback I ever get about these cookbooks is, well, they just work. And you think we'd be proud of that, but we know we can make this stuff better. And we want more feedback. Just works doesn't help us make it better. It works. That's great. But we need to know what we're missing. The container story I know is huge. Everyone's starting to love containers. So we're starting to move in that direction. We have support for the Nova Jocker driver. But with Magnum, that's my personal goal, is by the time we get to Austin, I'll have a Magnum cookbook that I think our community can be proud of. And with that, thank you for coming. Appreciate your time. Have a great conference.