 Hello, my name is Matt Ray. I'm a senior technical evangelist with OpsCode. I'm here today to talk about what OpsCode is doing with OpenStack and what we do with Chef, our open source product. So what is Chef and why do you care? Chef is based on the idea of infrastructure as code. This is the ability to programmatically provision and configure everything in your infrastructure, everything that a sysadman would do to a machine. Chef is going to do that for you. And everything you do is tracked in version control. So you can treat it like any other source code. You can fork it. You can share it. But the key is you can reconstruct your business, your applications with nothing but a code repository and backups of your data and access to new bare metal or another cloud provider or hopefully OpenStack. And Chef does this by defining the policy for how your infrastructure is going to work. It doesn't say you have to know the exact details of how something gets configured. You say, hey, I need the Apache 2 package installed. I don't care how it's installed. If I change operating systems, I don't want to have to go and change the commands. Chef is going to handle that for you. You're declaring the policy that you want rather than how it's going to happen. The nodes actually configure themselves. So they ask the server, hey, what am I going to do? Hold down the cookbook and set up everything on the machine for myself. Chef is written in Ruby. The recipes that you write are done in Ruby. We chose Ruby because it's a very popular third generation programming language. Rather than have a limited domain specific language around configuration, so let's use a real programming language. So if I need to do something more extensible, if I need to contact an API, calculate something, talk to other machines, and generate something automatically, I have a programming language available to me. And so when you configure your infrastructure, you're going to use cookbooks. Cookbooks are a package that are how you configure a particular service or application. So a cookbook might be something like Apache or MySQL or Nova or Glance or Horizon. And inside that cookbook are recipes. A recipe is the actual Ruby code that runs on your machines that configures how they're set up. The cookbook also contains templates for config files, so you can share that across all your machines, as well as any source of scripts or any other resources you may need. But the point of a cookbook is it promotes code reuse and modularity. So there are over 900 cookbooks available on the AppsCode community site, where other people who are writing infrastructure just like you are sharing these libraries of infrastructure with other users. And I mentioned our community, because it's very important to AppsCode and to our Chef community. Chef is Apache to licensed, just like OpenStack. This means that you're free to do whatever you want with Chef as long as you don't apply patents to it. And because of this permissive licensing, we've had over 1,300 individuals contribute code to Chef or some of the other Chef-related products. We have over 200 corporate contributors. This means companies like Dell, Dreamhost, HP, Rackspace, VMware, SUSE, companies here at the OpenStack Summit, their employees are contributing code to Chef and writing cookbooks and making sure that you are able to deploy infrastructure just like they do. And I said before, there are over 900 cookbooks available on our community site. The point OpenStack is done with cookbooks. We have cookbooks for all the major pieces. Chef is going to tie everything together. One of the key features of Chef is our use of search. So rather than have to know in advance how all your machines talk to each other, Chef is going to use search. So when I have a Nova compute node, it spins up and says, hey, where is the API? Where is my sender? Where are the various services that I need to consume? It doesn't have to know the IP addresses in advance or the credentials it says to the Chef server. What are the machines? I'm looking for this. How can I talk to that? And the Chef server says, here's what I know. Here's the other, the Nova API that's checked in with me before here, the credentials, writes that out. If something changes, maybe we need to start clustering some of the nodes. Or maybe a node dies and needs to be replaced. Well, we can automatically replace it. And machines that depend on those services will get updated with the new configuration automatically. OpenStack is built out of interchangeable pieces. Some of them, you may want to change out different databases or different hypervisors. But all these things are shared, supported, and documented. And everything's under the Apache license, which makes it available to everyone to be able to configure this infrastructure themselves. This is a short list of some of the companies that are using Chef with OpenStack, companies that we work with as customers or open source users. A lot of people here that you might recognize. They've got booths all around us. But what's really important is there's a critical mass around Chef and OpenStack. There are real people solving real problems. And we're happy to talk about some of them as well. But most of them have code up on GitHub. So if you want to deploy OpenStack like Rackspace, if you want to deploy OpenStack like AT&T, or you need a nice Siri MVP cookbook, all that stuff's up on GitHub. So why? Why is there a community around this stuff? Well, at previous OpenStack summits, I'd get up and I'd talk about how Rackspace was doing something and Dell was doing something and Mercado Libre and each on and on. But none of them were collaborating. None of them were really incentive to collaborate or work with each other. What we wanted to do was reduce the fragmentation, encourage this collaboration. Because deploying OpenStack, that's not secret sauce. There's documentation. You follow the guides. You will get OpenStack. That shouldn't be your business differentiator. What should be your differentiator is the fact that you offer something like fanatical support or your long-lasting engagement with your customers. And so we have a project around it. It's not something that OpsCode sells. We're not an OpenStack vendor. It's just something that we want other people to have success with OpenStack. So what is it? It's a chef repository for deploying OpenStack. It's documentation. It's cookbooks. Mentioned before what cookbooks are, but they're cookbooks for the seven major components. And it's a Knife OpenStack. So Knife OpenStack, Knife is our command line tool for talking to APIs. It's what we use to talk to our own API so we can query the Chef server and gather information. But it also talks to cloud APIs. In this case, it talks to the OpenStack API. So we're able to gather information from the Nova API. We can find the list of the flavors, the security groups, the images. And we can create and delete servers from the command line. Looks like that. And given this command, I don't have to log into the web UI. I don't have to go on the horizon and click around. I just run this command and a new server will get spun up. I can pass it a run list and say, you need to be a Hadoop worker when you're provisioned. You need to become a LAMP stack. You pass all these things from the command line and you can quickly create new machines automatically. There it is. It shows up in the dashboard. Knife OpenStack is compatible with just about every vendor out there. Most of the people are providing OpenStack. We've worked with them at some point or we're partnering with them. But people may not be standing OpenStack up with Chef, but their chances are very good that they're gonna be running their infrastructure on top of OpenStack with Chef. And so that's why compatibility is important. But it's not just about OpenStack. What's really important is having infrastructure portability. You need to be able to move your infrastructure, your business's applications, wherever you want to go. Whether it's EC2, Rackspace, OpenStack, it doesn't matter. They're well-supported plugins for all of these and it makes it easy to move your infrastructure from one cloud provider to another, hypervisor to another, bare metal to cloud. It's all easy to do when everything is managed with Chef. So any questions? Yes? Yes. So the question was, how well do we support OpenSource Chef? We recently came out with the new release, Chef 11. The major new feature of Chef 11 was the fact that we rewrote the core engine for converting some of the internal APIs from Ruby to Erlang, moved off from Couch to Postgres. That's all OpenSource. And the reason we OpenSource is, we don't want two code bases. So hosted and private Chef, our commercial products are the same code base as OpenSource Chef. So the main, those Chef components are the same. OpenSource Chef is actually the fastest Chef available to you as a Chef user because it doesn't have all the fine-grained access controls that are in the commercial versions. When we released it, we also put out a press release with a partner of ours called Cycle Computing. They were able to do 10,000 machines with a single Chef server. So that's, OpenSource Chef is always going to be part of what we are. OpenSource is very important to Opscode. So and as well, we also released a new full stack installer of the Chef server. So installing it is even easier. It's a single dev or RPM that has all the dependencies and already tuned for a high-performance Chef server. A single package installs into Ops Chef server. It has scripts that manage how it's configured automatically. That's how we run our own infrastructure with Private Chef. And it makes it easy to run Chef on top of Red Hat, 5, Red Hat 6, Ubuntu, Debian, it all works. So very dedicated to OpenSource. Okay, any other questions? Thanks a lot.