 My name is Matt Ray, I'm a Senior Technical Evangelist with OpsCode. We are the company behind Chef, which I'm going to talk a little bit about. If you have more questions about Chef afterwards, please, you know, follow up with us at the booth. But, you know, the main focus of today's talk is going to be about Chef for OpenStack. So let's go ahead and jump into it. As you may or may not be aware, deploying OpenStack is not as simple as it should be once you go past one box. We all love DevStack, but really you need to be on more than one machine if you're going to be running anything at scale. So I'm here to tell you that Chef makes it easier, of course, you know, that's my pitch on it. But first, I want to talk about the problem space, you know, you're, let's say you're a small startup and you have an application, you know, your business is pretty simple. You've got your app and it's up on a box and, you know, things are going well. You're starting to iterate over it. You've gone online, you know, identified a little bit of a bottleneck at the database. So, you know, we're going to move that on to another machine. And then we're going to need, you know, two of those, of course. And as, you know, as things get better and better, well, we turn out we need two application servers. And of course, you want a load balancer in front of them because, you know, you want them to have the same IP. And, you know, things are going to continue to grow and grow and, you know, put in some caching and things get better. But all these things are tied together with configuration, you know. All these machines are talking to each other and they need to know about, you know, what everyone else is doing. I mean, the application servers are trying to talk to a database. So they need the caching layer, you know. And of course, maybe you don't want to do it that way. Every infrastructure is kind of a unique snowflake. I mean, you can stamp these things out, but I can tell you that, you know, HP's OpenStack does not look like Rackspace's OpenStack behind the scenes. So everyone's infrastructure is a unique snowflake, you know. Servers, they're pretty much interchangeable. But infrastructure, it's pretty unique. And as you start to grow and evolve and scale, you know, you're going to change out parts. Maybe, you know, MySQL's not working out for you and Postgres is where you want to be. This is going to introduce some NoSQL to your stack. Well, you know, things are going to continue to change. And as you continue to gather success, you're going to want to move into multiple data centers. So you're going to have to recreate what you have, that you've carefully curated in data center one into two and three. And, you know, and with all this complexity and success, you know, your infrastructure is going to continue to evolve and change. You know, machines come and go. That's great, right? I'm going to go ahead and have a seat. But that's all great and all, but you really want to hear about Chef, of course. So as your infrastructure changes, you're going to need to capture those changes. So Chef is built on the idea of infrastructure as code. This is a pretty central concept for kind of the big DevOps movement. Maybe you've heard about it. But it's based on the idea that everything you do to your servers is captured in source code. And because it's source code, you treat it like source code. You commit it to a version control system, you know, like Git or Subversion or something like that. You make versions of it. You tag it. You branch it. You patch it, you know, just like any other code base. And the idea behind this is the reason you want to do this is you can reconstruct your business from source control and backups and, you know, access to new bare metal resources, you know, and data center two, data center three, or a different cloud, you know. So as you need to move your infrastructure around, you can do that because you know how everything works together. So in Chef, Chef follows a client server model. We call our client, the clients are on nodes. So the Chef client runs on a node. It generates configuration for that node. It asks the Chef server, hey, what am I supposed to do? And the server says, you are a Nova API. You know, you are a Hadoop worker. You are, you know, you're going to do this. And the server goes, configures itself, sets up all the right software, and then it's going to push its information back to the server. It says, hey, I'm all configured here. You know, Nova API ready for business. And, you know, everything's looking good. And this is all backed in version control, of course. And so that node is an abstraction of a server. And the things that you do on that node is you work with resources. Resources are abstractions of things that system administrators do. You know, whether it's installing packages or writing config files or creating users and directories and managing your networking, those are things that sysadmins do. Chef has resources to represent those. Now, these resources are just an abstraction away from what the actual underlying implementation is. Chef is giving you a declarative interface to your resources. You're saying, I want this package installed. You're not saying apt-get install-y apache2. You're just saying, put it on this box. So when you move package apache2 to Red Hat, it just works, because there's a yam provider. And so underneath the resource are providers that do the dirty work. There's a yam, an apt, depackage, whatever, that are going to implement what you want. But what this allows you to do is define the policy you want to implement. You want these servers to talk to each other. You don't care about the details. So you're declaring how they work together. So you gather these resources together in recipes. Recipe is just an ordered list of the resources and how you want them to be applied, the exact same order every time, which is nice, because you can reason on it. And you take those recipes and you package them in cookbooks. A cookbook is everything you need to provide a particular service. So an apache2 cookbook, a Hadoop cookbook, Nova cookbook, a Horizon cookbook. And you abstract out the attributes that you want to change, like the users that you're going to have, the directories, the pool sizes, the thread count, the things that you may tweak in a particular package. You turn those into attributes. And what this allows is you to reuse these cookbooks for any sort of application. And there's literally hundreds of them on communityopscode.com, like 600 as of this morning, where people are sharing how they implement, how to deploy just about everything. And so Chef is written in Ruby. And rather than have a domain-specific language for configuring things, we use Ruby. It's a nice programming language. It allows us to do things like assign variables and iterate over loops and calculate things dynamically. Because it's written in Ruby, maybe your recipes might need to configure something by talking to a web service or using some third-party library that's already written in Ruby, where you have all that flexibility and power available to your configuration management system. You're not limited to what you can do. And because all this information that we've gathered on the nodes has been pushed up to the server, the server exposes it for search. And so we can use that search to tie our machines together. I don't have to have a spreadsheet in advance that says, my SQL database on IP address this, this, this talks to this guy. I just say, my SQL database is up. And so when I need to have another machine talk to it, it asks the Chef server, I want to search for the nodes. I want their web servers. This is an example using HAProxy. It's a software load balancer. I'm saying, find me the pool members who are running the web server role. I want to write out my HAProxy config with those guys. It writes out the HAProxy config. So maybe today I have five web servers. Next time this guy runs, maybe we have 15 web servers. It rewrites the config file, restarts the service. And I'm now balancing all those applications together. And so when you have an infrastructure that looks like this, and you add another box, those updates can become automatic. And just this one extra node has 12 resource changes. That's not something you want to do by hand, because chances are good, you're going to mess up. I mean, you're pretty good. But when you do this 100 times, you might mess up. And so Chef allows you to build just about anything, whether it's workstations or clusters or infrastructure as a service. Chef is going to help you build that. And it helps you automatically reconfigure everything. We have clients for Linux, Windows, Unix, BSDs. It works great with load balancers, with metrics collections, with monitoring, because those things are dynamic. A new machine comes online, it's automatically monitored. And you know exactly what ports to listen on. You know exactly how to talk to it. And so moving things in and out of clouds becomes trivial, because you've abstracted away the underlying infrastructure. So that's great, right? But the Chef community is what makes this all happen. Chef is Apache licensed, which is very permissive. It's what OpenStack itself is licensed under. It means that we've had over 900 individuals outside of ops code contribute code to Chef. These are people at companies like HP and Dell and Rack Space and VMware, Calzada, SUSE, people in the room, people out in the halls, they're contributing, they're writing cookbooks and they're sharing. So how does this all tie back to OpenStack? So we've got a project called Chef for OpenStack. It's a project. It's not a product, key distinction there. Why? So at the last OpenStack summit, there were a lot of people, I gave a similar talk and I said, HP's doing cool stuff and Mercado Libre's doing cool stuff and Rack Space and Dell, and they're all doing stuff separately. And what the feedback was was they would really like to collaborate, but it's hard for them to tell their boss, hey, over here at HP, we want to work with Dell. Or Rack Space wants to work with three most. And so we formed a community project. It's called Chef for OpenStack with the goal of reducing fragmentation and encouraging collaboration because deploying OpenStack is not secret sauce. The secret sauce is your business, whether it's fanatical support like Rack Space or cutting edge infrastructure. That should be your secret sauce. Getting OpenStack up, please, don't make that harder than it already is. And everything we do is Apache licensed. So the what? It is a Chef repository for deploying OpenStack. This contains all of the roles, the attributes, the environments, how these things tie together, how they work together with Chef with documentation. Documentation is very important. Like the shout out to Ann Gentel, doing great work with Doc's OpenStack. It's also cookbooks, a cookbook for Keystone Glance, Nova Horizon Swift, as well as a knife plug-in for OpenStack. I'll talk to you more about that in a minute. The code's all up there. If you go to opscode.com, OpenStack, that's kind of a landing page, it'll have all these URLs for you. We have a mailing list, Google Groups, we have an IRC channel, most of the contributors hang out in IRC. A lot of good conversations happen there. All this code is up on GitHub, so please go contribute for pull request. It's all great. I hear some of the people who stood up and said, hey, we're working on this. A lot of good names up there. And there's a lot of people who aren't on this list that are still contributing. So there are no barriers to entry. It's Apache license. We're trying to make it as easy as possible to deploy whatever you need. Rackspace Private Cloud, their Alamo project, it's the same code base. I mean, it's a parallel fork. They're taking it, and they're making it easy to install OpenStack. This is a great way to get your feet wet. If you haven't already checked it out, please check it out. It was one of the initial sources in the cookbooks, based on work that had been done with some other people. And so that is all OpenSource as well. So if you want to go to Rackspace's version, it's there. If you want to go to DreamHose version, it's also up there on OSOps. So this code is all up there. And they have really great documentation. So whoever did that, thanks. So what is there currently out there? Essex is working. We support fairly smallish installations, maybe less than 100 nodes, because we're still kind of stabilizing it before we really start changing out the underlying pieces. But it's KVM and Ubuntu 1204. Alex C work has been done by Calzada. Red Hat work has already been started. I could talk more about that. We're open to pretty much supporting anything. If I know there's some SUSE folks around, we'd be happy to support SUSE. It's pretty much if you have a feature you want supported and your patches don't break everybody else, we'll take them. Because this is a community. Nobody's, you vote with your feet. You vote with your code. Folsom work has already started. A lot of people have told me, oh yeah, it was just great. Or we had to tweak two or three little things in Horizon, all that's coming. And definitely once the Grizzly milestones start up, people will start jumping on Grizzly before too long. Documentation. The documentation has been moved into a separate project because we want to provide high-quality docs that we can move into docsopenstack.org. These are in Sphinx and restructured text. And the nice thing about the documentation is it's backed by examples. So I have documentation for how my lab in my office is set up. And there are several people who have recreated it. They're like, oh, I use this network card and this network card. I mean, not even the same models, but just, you know. If I have two NICs and I want to roll out a small lab deployment, I can do it the exact same way. And I can say, oh, yeah, that's cool. Here's what it looks like. And also, you can tie it back to the Rackspace docs to see as you start to scale up even more. So what's really important here is that Chef is tying everything together. As you start to grow and scale your deployment, you don't want to have to go and touch another box. You just want to say, hey, another compute node. Or, hey, we're adding more to the cluster here. But scaling is going to change how we deploy. And so right now, most of the documentation is around the N plus 1 model of N compute nodes and one controller. We've already been told that work has been done to move the services onto separate boxes. I'll be looking closely at the HA work that's being documented and whatever else people show up with. So whatever is available to us is pretty much where it goes. And the licensing is there to make it available to everyone. So let's change it up a little bit. Knife OpenStack is our tool for talking to OpenStack clusters. So we can use Chef to deploy OpenStack, but we can also use Chef to manage anything on top of OpenStack. So Knife is the command line tool for Chef. It is a Swiss Army Knife of web APIs. It talks to the Chef server API. It talks to cloud APIs. So I can talk to the OpenStack API. And I can do things like list the flavors, the images, create and delete servers, list out the servers, and bootstrap new ones. All the basics list the flavors, what's available to me, list the images that are my current system. But what's cool is I can say Knife OpenStack's server create. And from the command line, I can create new instances without having to go into the dashboard and click and say this and this. I can also pass a run list to this. So I can tell it, hey, I want to go to this OpenStack API, create me a medium server of Ubuntu 1204. And that's going to be a Hadoop worker. And I could run this 10 times. I have 10 Hadoop workers. And they're going to use Search to find the Hadoop master. And I'm now running a 11 node cluster without touching a UI. And this makes it easy to scale. And I can also say Knife OpenStack's server delete to reclaim those boxes as I go. So I can start actually using my cloud like you want to use a real cloud. It's not just, hey, I stood something up in the corner. Now we can treat it just like everything else. And that machine shows up on the dashboard, of course. That's all pretty. And you can log into it. But that OpenStack plugin looks a lot like the HP plugin. It looks a lot like the Rackspace V2 plugin. Because there's a lot of shared code there. Those guys are based on OpenStack. But I can also move my infrastructure from OpenStack to EC2 to VMware to Azure to Google Compute. What Chef allows you, what Chef gives you, is infrastructure portability. So I can do, the dream of the hybrid cloud can be real. I can have an OpenStack cluster for testing and development. And use the same Knife commands, Knife EC2, server create to bring up my instances on AWS, or on Rackspace, or wherever. So what's on the roadmap? The roadmap is we had a session yesterday afternoon where kind of people identified the things that they're working on. My main focus is I'm kind of outnumbered. There's a lot more people in the community than just me, which is a good thing. I'm essentially the documenter and community manager. And I'm documenting how these things work and trying to get people to succeed with the code. We currently support KVM, but LXC support is in a Calzada branch, and we'll be sure to bring that in. Hyper-V makes really good sense with Chef, because Chef treats Windows like a first class citizen. So we have, if you're a Windows guy, probably not this crowd, but everything you want to do in a Windows box, we can do. And Hyper-V makes sense in a mixed cloud, because it's cheaper to run Windows VMs on Hyper-V than any other platform because of licensing. So if you need to do that, that's a great way to do that, because everything else will be on Linux. Database work, right now it's MySQL. There are some people who don't like MySQL, and they said, I'm going to bring in Postgres support. And I said, thanks. Operating systems, Red Hat 6, of course, is coming very soon into the source space. Debian has packages. If people want Debian support, I'm happy to merge. And add that. SUSE, of course, we're happy to have whoever shows up is what we're going to add. They share configuration is not documented with Folsom, so we will be going through that to make sure that we have Pacemaker and Galera working and RabbitMQ working, as well as changing out some of those components for other options, whether it's Cupid or ZeroMQ, whatever OpenStack supports, we want to support. If somebody is going to want that in their cloud. And I'm happy to do that. Quantum work has been started. DreamHose told me that they have done some work to make NYSERA work, as well as OVF. So there's already a pluggable quantum cookbook that should get merged soon. So if you're a quantum vendor, the framework is there for you to plug in your quantum solution into this infrastructure that is getting used by a lot of people for real deployments. If you're a sender vendor, if you're a storage vendor, the DreamHose guys, of course, they're pushing staff, but you could put pretty much any back end in there. And that will be pluggable and supportable however we want. There have been a couple of Chef for OpenStack hack days where DreamHose hosted one, Rackspace hosted one. There's going to be one in New York City next month. Essentially, we show up and fix bugs, talk about the code, work on the roadmap. It's a community thing. I'm trying to get one for Boston and somewhere else beyond maybe Australia, we'll see. So but Chef for OpenStack is also good for the greater Chef ecosystem. If you're a Chef user and you're not doing OpenStack, there's a halo effect of things that are coming out of the project. The MySQL cookbook has gotten a lot of work. The RabbitMQ cookbook has gotten a lot of work because people are actually using those things in production environments. And so the cookbooks have to be capable of supporting all the features that you want. We have a project called Test Kitchen, an open source test framework that you, we use it for testing cookbooks, but it could be used to test anything that's built on top of vagrant. And you give it the images that you, the operating systems and the architectures you want to support. So you know, Ubuntu 10.04 on 32-bit, and it will run sets of tests, tear down the machine, run the next set of tests. Well, one of the nice side effects is somebody's already moving it off a vagrant to OpenStack. So we'll have Test Kitchen, we'll have support for OpenStack. So we'll be able to run probably a lot faster than vagrant on your desktop. Librarian is a Chef community tool for managing your cookbooks. We started using it with Chef for OpenStack and it's been very beneficial. And there's lots of tools in the Chef community that solve that problem. SpiceWizel is another tool that deploys your infrastructure for you. Chef for OpenStack uses it, it manages your roles and environments and everything. The work for Chef for OpenStack to get it at working with SpiceWizel has made SpiceWizel better and applicable to other use cases. PixieDust is a minimal pixie-booting solution. Again, Chef for OpenStack has gotten people solving weird edge cases with pre-installing OSes before you can run OpenStack on them. Network card ordering and that sort of stuff. And of course KnifeRackSpace, HP, DreamHouse, they all are based off Knife OpenStack. It's a lot of shared code. And so because those guys are throwing up OpenStack Clouds, it's easy to support them immediately with Chef. So if you are a vendor, if you are an infrastructure as a service vendor and you throw up an OpenStack Cloud, it'll get supported really quickly by Chef. And I can tell you your customers will appreciate that. And of course Dell's Crowbar project. It's a hardware installer for managing your data center. There's a lot of overlap between the work they're doing and what we're working on. So too long, didn't listen. Here's what's going on. Opscode.com OpenStack, it's a project, not a product. Lots of real contributors, RackSpace, Dell, HP, Dream Host, AT&T, others. Essex is working. Folsom's already started. The features are driven by demand. And we have lots of good documentation and working on examples for each piece. So any questions? There's somebody in the back. No, no. So the question is, would I consider Vagrant to be competition with Chef? Vagrant is a VM framework for quickly bringing up operating systems and on the desktop and tearing them down. We worked with Mitchell Hashimoto, the Vagrant lead a lot. We love Vagrant. We use it all over the place. It's a great way if you're a desktop developer and you have virtual box, it's a great way to get desktop virtualization just quickly cycling through your machines. The things that you run on top of that, it's going to be done with Chef. So Vagrant uses Chef to configure the machines that are on it. So Vagrant brings them up, Chef puts it on top. No, but we definitely love Vagrant. Question? I know you've been around as long as Puppet has, or pretty close to that. But do you know roughly what your market penetration is? People using Chef versus Puppet, using CF Engine, even Juju, which is also Juju as well. So we actually are coming up on our fourth birthday. So Puppet's twice as old. Chef was founded by some people who had used Puppet at large scale. And we're running into some of the issues that I talk about, like search and those sorts of things. And so there were some just differences in philosophy about how infrastructure should be managed. As far as market cap, I can't really speak to that. As far as open stack deployments, I can walk down the hall and point out who's using Chef. And it's a lot of people here. And I think, but if any Puppet people here, they're doing good stuff, too. Like we like to say, as long as you're using configuration management, you've already got a leg up on a lot of people. So go to Dan Bode's talk and ask him. Any other questions? Yeah. I live in Austin. We don't have soccer. So yeah, if there are no further questions, please hit me up on email, Twitter, IRC. Thanks a lot. Stop by the booth.