 Okay, let's go ahead and get started. We've got a fairly long session today, but this is meant to be informal. So if you have questions, don't hesitate to throw a hand in the air. If I go over something too fast, if you need clarification, please let us know. We want you to get something out of this. And if I just sit up here and talk for a while, you'll get bored. I'll probably get bored, Justin will get bored. But let's go ahead and dive into our agenda today. We're going to give a quick background of what Chef for OpenStack is, what the project's doing, what sort of resources are available for you if you're using Chef and OpenStack together, whether you're deploying it or a consumer of OpenStack, we'll go into what your options are there. We're going to do a deep dive walkthrough of deploying OpenStack with Vagrant, possibly Ice House, we definitely have Havana working, Ice House is booting. And then the instructions are at that bit.ly link. It's a gist that just walks through all the steps. So everything we do in the live demo and the walkthrough, you'll be able to follow probably from home. We'll all kill the Wi-Fi here. Oh, hey. Hey, guys. I'll have to talk a lot. That's not the puppet, guys. So that's our agenda for today. Quick introductions. Mr. Justin Shepherd. Justin Shepherd, Rackspace, Principal Architect. I work on the private cloud team for Rackspace, so we do private cloud installations for customers all over the world. Okay. I'm Matt Ray. I'm with Chef Software. I'm the director of partner integration, so I make sure Chef works with your stuff or other people's stuff, whoever's stuff. And email, GitHub, IRC, Twitter, it's all the same. So an overview of Chef for OpenStack. What do we currently have going? What's the state of the project? So Chef for OpenStack is a project. We've been coming to these OpenStack sessions. This is my, I don't know, I've been to all of them. This is my Nth OpenStack summit, and I've spoken to most of them because people deploying OpenStack are using Chef. A lot of different folks are using it, but over the years, the first set of cookbooks we wrote were for Anso Labs, and those were for Bear, and those have morphed, and people have forked them. They've been on GitHub, Apache licensed, and they have a long twisted genealogy of different people, but we finally got everyone back together onto Stackforge, because we kind of pointed out that putting a community around deploying OpenStack makes a lot more sense than trying to differentiate on how you stand up the same product. So in order to reduce fragmentation and increase the collaboration, we formed a community. Deploying OpenStack should not be secret sauce. It's hard enough, as it is, we might as well work together. So we formed a project. We call it Chef for OpenStack. It has a lot of different companies involved, a lot of different deployers, a lot of different people productizing it, but it's all Apache licensed, so you're free to do whatever you want with it. Since it's a community, we have an IRC channel. OpenStack Chef on IRC FreeNode. We have a mailing list. It's a Google group, OpsCode Chef OpenStack. We have an IRC, a Twitter handle, Chef OpenStack, low, low traffic, except for today. And we have a weekly meeting. So every Monday, 11 a.m. Eastern, we have a Google Hangout, and 10 or so people show up, and those are recorded in case you miss it, or time zones don't work out, but we kind of walk through the week's news. We say, hey, what's the status of these blueprints? What are the status of these reviews? Who's working on this feature? Have you run into this issue? Just to stay on top of it. And usually the representatives from IBM, from Rackspace, from Dell, from AT&T, whoever, they all drop in the channel and get feedback. And if you look on Stakelytics, you can actually see the contributions over time. So there's a quick list of who's involved over about the last six months. Some of those companies are taking it and making commercial products of it, like Rackspace, like IBM. Some of them are deploying it in production for themselves, like AT&T, like Dreamhost, and Createlecom. And so this is a mix of real users and employers. So it's an active community. Here's, I took a snapshot of Stakelytics last night. You can see it goes all the way back to April, 2011. So that's when we showed up on Stackforge. Or at least that's where the Stakelytics understood how far back we went. And you can see the pie chart of contributors, AT&T. This was their branch of the Rackspace ones and the Dreamhost ones. The genealogy is all there, but you can see it's fairly heterogeneous. We have a lot of different vendors. It's not like, hey, this is the Rackspace cookbooks and everyone else gets what they get. It's a real community. So diving into the actual code. If you're using Chef, these requirements shouldn't seem too outrageous. We require you to use Chef 11. That's the current release. We do stay on the edge of what's currently stable and released. So we try to take advantage of all the latest features that are available with Chef. We used to specify that you use the Omnibus Chef client. We backed off that and said, hey, it needs to be Ruby 1.9 at least. Some of the gems that we use require Ruby 1.9. The Chef client will move to a newer version of Ruby soon. But for now, we'll just keep saying Chef 11. We use Food Critic, Chef Spec, and RuboCop for our testing. Food Critic is a lint tool for cookbooks. If you haven't used it, it tells you what to look out for in your code. Chef Spec is our spec test for Chef infrastructure. We have a lot of those. Maybe several thousand. It's ridiculous how many tests we do. And what Chef Spec does is it actually instantiates Chef nodes and runs the cookbooks and verifies that test happened or that the things that you asserted were going to happen, happen, and it's fast. So that's what's nice about Chef Spec. And that's part of the gating that we get from being on Stackforge. And RuboCop is a Ruby code quality tool. So we try to have some standardization about how we code our Ruby because we have a lot of different people on the same code base. Maybe you don't like the way RuboCop does it, but it's a standard. So at least we can agree on that. The cookbooks are driven through attributes. So we don't have a lot of hard-coded values. Everything gets exposed by an attribute. So if you need to change which database you're using, which hypervisor you're using, which messaging queue you're using, those are all driven by attributes. And the different settings that those have, the ports they listen on. Everything is pulled out by attributes. And that way, the cookbooks are very reusable across different operating systems, across different platforms. We put a lot of the platform logic between the different operating systems. We put those in the attribute files. So this is a fairly new pattern. If you're a long-term Chef developer, you've probably gotten onto this track. But we put the logic for your platforms in the attributes file. So we actually say, hey, if we're on CentOS, your package files are called this. The name of Nova of OpenStack API is this. But if you're on Ubuntu, it's different. They have a different package name. And so we just roll those into attributes, key off the platform, and hide that from the recipes, which makes the recipes easier to use. Currently, the cookbooks deploy OpenStack via packages. And packages, meaning for Ubuntu, we're using the LTS packages from their PPA. Cloud Archive. And yeah, Cloud Archive. And for Red Hat, we actually support. It's a mix of the RDO and Apple stuff. Yeah, the RDO, the Apple stuff, and IBM has their own Red Hat packages that are supported. But it's hidden away from you as an end user unless you care, and it's over in the attributes files. So that's what's going on in the Chef, a little meta there. The cookbooks themselves, oh, we already have a question. First question. We'll repeat your question. Or do I just yell? Talk like you yell. Yeah. At the risk of courting controversy, this seems like the kind of thing that would be an almost drop-in replacement for DevStack with the last bullet point being changed to, say, pull from Git repos and whatnot. And having the opinion that DevStack is a cantanker's Rube Goldberg contraption that solves a problem that is already very much solved by configuration managers, are you guys gunning for taking over that space, eating their lunch, making it such that you can use the exact same tool to deploy to production or development programs, et cetera, et cetera? No. We have no intention of replacing DevStack. We have a hard enough time deploying stable releases of OpenStack that we don't really wanna chase trunk. That said, we are working on trunk now. I don't think there is a desire, you know, we will take the patches to make source builds work. You know, as we talk about these cookbooks, the point is really, it supports a lot of things, but the things that are supported are things that people actually use. So rather than try to support every single permutation, if you see support for ESX as a hypervisor, that's because IBM is actually shipping that and testing it. You know, if you see support for, you know, KVM and MySQL and Postgres, we actually use those in production. You know, so, you know, if you wanted to do source builds, you know, show up with your patches, don't break other people's stuff and you're good to go. Chasing DevStack, though, is not our goal. And actually, I mean, I think DevStack has a pretty useful case right this second. It's great for being able to spin up a cloud with some random set of options that you want to be able to get it up and they use it for all the testing stuff, whereas with the Chef stuff, it really is meant to be for running a cloud and, you know, as you go along, you realize that your memory over commit rate is set wrong. So you go into the attribute file, update the attribute, run Chef Client on all your nodes. Now you have the right settings and it's more of a continuous management versus a spin up to test, which is what DevStack does really well against trunk. I mean, you know, Chef is an operations tool. It's not an installer. I mean, we're happy to support that and we'll talk some more about how you could do that because there are definitely people who are running trunk and not using the packages from the districts. Thank you. And that's the kind of question we like to hear. So the cookbooks, they're official OpenStack, StackForge cookbooks. I think if you work on them, you get ATC on your badge and they're cookbook, OpenStack, up on GitHub, StackForge, that's where they are and they go through the CI provided by OpenStack. So the same Zool that runs 900 commits an hour, we're on that too. And... Garret code reviews, all that. Yeah, the Garret code reviews, the CLA covered by OpenStack. We support all the current stable services. So for Havana, we have the block storage, common compute dashboard identity image, telemetry. We really named metering to telemetry. Network, object storage, orchestration and test integration. So that's, test and integration is tempest. For Ice House, very soon we will be adding Trove and Sahara. And then we have three support cookbooks that they're not OpenStack projects, but they're reference implementations if you need to stand up Ceph, a MySQL or Postgres database or Cupid or RabbitMQ. Those are those support cookbooks. And we'd be happy to support other messaging queues or other databases. These are just wrapper cookbooks to configure that for OpenStack usage. For deployment, we actually have a Chef repository. We're gonna be walking through some of this today. For, we have a Chef, an OpenStack Chef repo. There's the GitHub URL that has vagrant files for deploying OpenStack. That's what we're walking through today. That has example environments and roles. So you can see how you could wire these different pieces together. And the Chef repo is also gated by OpenStack's review system. Linting the files, making sure that the actual code that gets committed into the Chef repo would actually stand up an OpenStack, at least a reference implementation. And we're gonna continue to build out those deployments. Right now it's mostly single node and small deployments. Yes, question. It's Trevor from RMS. I'm curious if you guys have the Holy Grail of transitioning between upgrades basically between the different versions. So we have done blueprints for upgrades? So upgrades are a little bit funky with that. So obviously, Icehouse is kind of the first version where you could do the rolling upgrades. So there's always been that problem. Some of them, whenever you're doing package upgrades, it can do package upgrades. So you can switch out the repo to the next version. You can go through and do Chef Runs. You have to control which Chef Runs in what order. And so you kind of go like, I have a controller, I'm gonna do a controller, then a compute, and a compute, and back to the controller, and those two. There's some stuff that crops up where you have to run a script off to the side. And that changes every single upgrade. There's always one of those. Two upgrades ago, it was Keystone. You had to go and do something to change the database before you did an upgrade. So there's still some of that. And there's not a great way for expressing that, Chef. And so you end up having to do Chef Run, Chef Run, Chef Run. One of them fails because you need to run this script, run this script, go back and run it, and then you can progress through them. So there is the capabilities there. We're actively working on a better solution. And we're talking about doing one-shot recipes so that you can compose those pieces that don't really fit well into it. Add it to your run list. Go do a Chef Run, pop it off of your run list, and then move forward. So that's an active blueprint that's open right at the second. And the pattern would be when we have the Ice House, in the Ice House cookbook for, say, glance, there would be a recipe in there called Havana Upgrade. And then when we go to Juno, there would be an Ice House upgrade. And so you could actually potentially follow through all of those and upgrade your glance bumping to your run list to include that recipe. And then either as a one-shot or remove it when you're done. Or use an attribute to include that recipe. So it's definitely something we've talked about, and we just haven't committed to actually doing it yet, because it's hard. We're working through it though. Ripping replaces easier. So implementation, the reference to the implementation, there's also, it's backed by documentation that's a little stale, I think it's still for Grizzly. But in the documentation, there's examples of how to do an all-in-one compute, which we'll be walking through today, how to do a single controller plus a compute. We need to add the open stack docs themselves now use a one plus one plus in, one as a network controller if you're running Neutron. We'll see more about the docs here in a second, but we also wanna talk about different HA configurations that are supported. SUSE, for example, has been working on a lot of pacemaker support, and we would not tell you that that's how you're going to do your HA story, but we would make sure that we could support that in the same set of cookbooks and provide examples. Things that we don't provide are operations activities, such as logging, monitoring, hardware provisioning. Those are all just crazy, separate big fields all on their own, so we're not gonna give you an opinion of how we think you should do that. We want you to have a stable open stack and then manage those pieces for you, and that's value add by other folks. There's a URL for the docs. docsopscode.com, open stack, HTML, but the point is the docs review some of the architecture, some of the deployment prereqs, how you would actually install this, what our development workflow looks like, and working with the cookbooks and the repositories, as well as documentation of my office lab, how it actually works. The docs are all up on GitHub. These are part of Chef's documentation, and they're all creative, commons licensed. There's no CLA required. If you make a pull request against them, it'll get merged usually within a day and be live on docsopscode.com, so please feel free to take these docs and expand them, contribute to them, whatever you need for your documentation. They are in Sphinx, which is the same restructure text through Sphinx, which is the same stuff that open stack docs use. The example deployments, we talk about all in one for development testing, either using Nova Network or Neutron with OVS, either Ubuntu 12.04 or CentOS 6.5. Working on adding 14.04? 14.04 is in progress. Does it work? No. Not yet. Not yet. And then my developer lab that other people have been able to recreate is a single controller with several compute boxes. And when I say consumer grade hardware, I mean cheap stuff from Fry's. For Grizzly, the stable Grizzly branch is there. There's not a lot of activity going on, obviously. But we had Ubuntu and Sles with MySQL, Rabbit, KVM, LXC, Quantum for OpenVswitch, LVM and Swift, and Apache Engine X. For Havana, the stable Havana branch is there. REL6, we're not going back in time to five. We're probably not gonna do Havana on 14.04, but the things that got added for the Havana release were DB2 and Postgres, Cupid support, ESX, Hyper-V, Linux Bridge for Neutron, and then several different block storage options got added as backends. Ceph, EMC and NetApp, and IBM has several product lines that are supported. For Icehouse, this is currently under development. We're actively working on the Icehouse branch right now. So a couple of things that we're gonna bring in Matt mentioned earlier, the Seth Cookbooks. We started talking to the DreamHouse guys and realized that their Cookbooks had been kind of staled. I mean, they were still using them, but there wasn't really a whole lot of work going on. And then it turns out that a lot of people in OpenStack wanted Seth Cookbooks. So we got them to move it over to Stack Forge and bring it into the fold. So that happened pretty recently. So there's gonna be a little bit of work to go back and get it kind of standardized with the rest of the Cookbooks, but we'll soon have... There already actually appeared in really good shape. I mean, Ink Tank had... They're all rubo-copped up. It totally works. It just needs to be a little more standardized. So then we'll get that in and it'll look and feel like the other Cookbooks. We'll be adding probably Trove and Sahara, since those two made it into integrated release status. There's lots of heat enhancements going on right now. So lots of work on getting that to kind of get beefed up, especially with the new HA model that came out in Icehouse. And then there's a lot of work going on on the neutron side. So the reference implementation that a lot of people had been going with previously was non-ML2 with OVS controlling L2 and L3. Most people have since then realized that that does not work great unless you are using open flow controllers. And if you're not, you're biting off a lot of operational complexity that you don't need. And so the ML2 driver came out and helped standardize the interface to neutron. So we're looking at doing a Linux bridge ML2 for layer two and then either OVS or Linux bridge for layer three. I think those are gonna be the two options that get landed. So there's a sizable group between IBM, Rackspace, Bluebox that are all kind of working on it right this second and digging in to get the neutron stuff going. And then the Juno branch, so Matt was talking about it a second ago. This last release what we did is we cut, so we want to be able to have the chef cookbooks release around the same time that OpenStack drops its releases, so then you have cookbooks that are capable of running the latest release. In this last cycle, whenever RC1 came out for Icehouse was when we cut over master branch development to start tracking Icehouse because we had been on the stable branch for a while. For the next cycles going through, we really want to keep stable branch as the active development until the third milestone and then switch over from that point all the way to have active development track trunk from milestone three all the way through release so that we're able to kind of ship a release at the same time that OpenStack ships it. So that's how we roll. Potential roadmap, these are things that people said, I would like to do this. And we said, if you show up with your code and it doesn't bring other people stuff we would love to support you. Debian has popped up multiple times on the mailing list. At the Hong Kong Summit, the Debian OpenStack maintainers said, our cookbooks are really easy to instrument. You can turn off the config and then you just get packages on boxes and that's how we really, that's what we really like. Bare Metal has been a hub spot we was using Bare Metal with Grizzly. That has kind of been flux. I don't think they upgraded and then Ironic happened that's kind of moving around. There's definitely people who still want to use Docker as their hypervisor or a hub hypervisor and there are folks using Zen who have said, hey, we need to get our stuff upstreamed because we are using this with Zen but they haven't done that. 0MQ was in for a while then it was out for a while it could come back. Again, if the code is supported and doesn't break stuff, we want it. There are fulsome cookbooks for NYSERA so they're pretty stale. So we could bring back VMWRs and SX, formerly NYSERA. Open Daylight, there are folks who said they want to work on that. We're happy to have it. It's just don't break stuff. And show up with tests. Obviously you have to have a lot of tests. Block storage, work's being done to flush out NetApp and some of the other vendors. And object storage, you know, Ceph is now in Stackforge so we're going to make sure that it's a viable backend for object storage, a viable backend for sender as well. And then we talked about source builds a little bit earlier. There's a project that Chef maintains called Omnibus. Omnibus is a installer builder for taking all the dependencies that your application needs and building a dev or an RPM, an MSI, a DMG, it's a cross-platform installation builder. It's what we use for building the Chef Client. It's what we use for building the Chef Server. It allows us to ship, in the case of the Chef Server, it allows us to ship a modern tool chain of Erlang, Java, and Ruby to things like Red Hat 5, to Windows, to Solaris. Things that have broken tool chains or ancient tool chains. It allows us to bring all of our dependencies with us. It builds big packages, but they're cross-platforms. So if you need to port your application to multiple platforms and multiple architectures, Omnibus is a great packaging system for that. People have been using it for Java, for Ruby, for Python applications, and there's now an Omnibus OpenStack. Omnibus OpenStack, there was a presentation at ChefConf about it. Craig Tracy from Bluebox is kind of the lead on that, but actually builds a fully self-contained OpenStack package that has latest version of Python, with all the Python libraries that you need. So if you need to build something that is not provided by your upstream vendors, if your distros are not packaging up your patches, with Omnibus, you can point to a Git repo and builds from that. And so if you need to build one-off OpenStack packages for your patches, if you need to support architectures that the distros aren't supporting, like, say, PowerPC or ARM, those things can be built with Omnibus. And so, Korea Telecom at ChefConf actually said, oh, we're running that in production at a fairly, you know, KT is a pretty big shop. And they're running Omnibus OpenStack on, you know, more than 100 nodes, more than 1,000 nodes. We'll leave it at that. Physical hosts. So Omnibus OpenStack will be definitely supported in the cookbooks going forward. And of course, you can do source builds on that and do, you know, continuous integration Omnibus builds of trunk. So, infrastructure roadmap. We mentioned that there would be, we'll be adding cookbooks for Trove and for Sahara, but also some of the tooling that we do around these cookbooks. ChefDK is a new project that we announced at ChefConf. ChefDK is all of the developer tools that you need for working with Chef, packaged up with Omnibus. So you have a working Chef tool chain of Chef Client, Chef Zero, Knife, Test Kitchen, Berkshelf, Food Critic, all the tools that you're using day-to-day with Chef. We have it packaged up for you with a DMG for OSX. We have Devs and RPMs for Lennoxes. An MSI is coming soon. And we've sorted out like, how do you get a working viable tool chain on Windows? Well, here's ChefDK. It handles all that for you and you don't have dependency incompatibilities between all the different Ruby projects. We'll be switching over to that just because it provides a lot of sanity. And we'll be demoing with that today. Test Kitchen and ServerSpec, we definitely need to continue to ramp up the amount of testing around these cookbooks. Right now, most of the testing is ChefSpec, which is just unit testing. Test Kitchen with ServerSpec would give us actual integration testing. So we'll see more about Test Kitchen in a bit. Right now, there's Spice Weasel Manifest for deploying the reference implementation, but we'll be switching to more Chef Metal and we'll see more about Chef Metal in a second. And then, of course, we have the Chef Community Summit in October. This is a conference, two days in Seattle where two or 300 Chef users show up and a hotel and we hash out the things that we care about and swap stories. It's definitely a good time and there's a lot of OpenStack conversations and things like the Omnibus OpenStack. Yeah, we sat down and hashed out how that would work and now people are shipping it. So a lot of good stuff happens there in October. So that's kind of the overview of what's going on for deploying OpenStack. But Knife is the tool that we use for integrating Chef with different APIs. This is our command line tool and Knife OpenStack is the one that we use to talk to OpenStack. Knife OpenStack allows you to deploy Chef infrastructure into OpenStack. It has commands, flavors, groups, images, networks, servers for handling those sorts of things. There's the currently available commands. So if you say a flavor list, it gives you the names that you have, the IDs, what they actually, the specs are. This is just the sort of things that you need to know about as you're deploying infrastructure on top of OpenStack. Flavor list, of course, image list, the names, the IDs, whether or not it's a snapshot. The networks, if you're using Neutron, you can actually, now you can list the networks that are available to connect to. You can list the security groups that are available. So as you're deploying infrastructure, you can say, hey, I know this is actually gonna be an HA proxy, so I'm gonna put him in the HA proxy security group. And then real tiny letters, but that's listing the currently deployed servers. Other names, the UIDs, what availability zone they belong to, the public and private IP addresses. If those are the names of your networks, there'll be more fixes around that coming. Yes, for Nova? It's parallel. If you're using Chef, you're probably using Knife, and we wanna make sure that you can use Knife OpenStack Server Create and you have access to the data that you need. You might not have a Nova tool chain on your developer workstation. This is just, we're gonna package up the Chef experience for you. And you can see the flavors, the images, which KeyPair was used and the current state, so whether they're shut off or active or build failed or whatever. Knife OpenStack Server Create has more flags than you can shake a stick at, just because it supports all the different weird network permutations that OpenStack supports, whether you're using KeyPairs or passwords, whether you're... Oh, question. Yes? It is making API calls. It talks, it uses Fog, the Ruby multi-cloud library, and talks to the OpenStack API. So, and you configure it, we'll see examples of how to configure it, but it's fairly straightforward. You put in your URL, your creds, and then you can just say Knife OpenStack Server List and you get output like that. And OpenStack Server Create, that's, there's like five pages of this, but I cut it off. Question? Yes? So the question is, are they direct API calls? Yes, Fog actually contacts the OpenStack, Knife under the covers uses Fog and says, hey, create me a OpenStack compute object. Here's the Keystone API URL, get that token, take that, list the services, make the calls. It is real API calls. There's no wrapping other tools. And Fog is really good for that, and it's pretty much a standard. So when you say Knife OpenStack Server Create, boom, you get Linux boxes, or Windows boxes created on the fly. But of course you can delete them, and you can delete them. One of the new features, if you've been using this tool for a while with the release from last week, is you can actually, now instead of using the UIDs for everything, you can actually use the names of your objects, so name of the server, the name of the network, name of your flavors and lists, and so purge works. So I can say Knife OpenStack Server Delete, the name of the node to delete, and I'll actually go and delete those off of the Chef server as well, as deleting them from the OpenStack server. Knife OpenStack works with just about anything. I haven't, if you have something that it doesn't work, let me know. Anecdotally works with all those clouds, and it's been working since Diablo. Real quick, how many people have actually used Knife OpenStack? Okay, so that's actually a significant portion of it hasn't. One thing that kind of got missed, and I'll touch it since we had a few questions on it, where Knife OpenStack usually fits into your tool chain as a Chef person, so I'm gonna be using Chef to deploy my infrastructure on top of a cloud. Knife Server Create allows you to also bootstrap against a Chef server and set the run list all in one shot. So I can have a Chef server on my cloud. I can have the configuration in the Knife file that points towards it, and then I can go and spin up an instance and say it automatically gets connected to that Chef server, so it'll pull down the Chef client and register itself, and I can set its run list. So I've already got roles and environment. I can say, okay, you're part of this environment, and you have this run list go, and so whenever it does the create, it actually does all of the Chef bootstrapping and Chef client runs after that, so at the end of it you get a box that's been provisioned by whatever your run list is. Right, that's actually a very good point. You don't have to use the UI. There's no clicking in the web UI, so if you were doing automated deployments in a CI environment with Jenkins or something like that, or you needed to batch load a whole bunch of machines, Knife OpenStack is how you can do that. Yeah, question? For AWS? Or for... No, for OpenStack. It's y'all maintain one for AWS. Right, right. There's not plans, but I would help you do that, and part of the thing that we try to do at Chef is we want the community to have really good top-notch cookbooks, and we want to help them write them, and we want, if we're not using something day to day, we don't wanna be the ones who manage the patches. So if we're gonna see more stuff about how you would work with heat and access of sorts of resources, I'm not sure we would be the ones to support them if we're not using that ourselves. If we don't dog food something, we wanna find somebody who does. If we don't use something in anger, the pull request pile up because it's like, it hasn't burned us yet. But so we've been moving community cookbooks out to communities that actually support them, like React is supported by Bashow. The Apache cookbook is supported by a big hospital that they've got developers who are all over that cookbook. So companies that focus on, they use that in production. We've been pushing those things out to maintainers. So if OpenStack, some of the resources, some of them we would use, I would definitely be very involved in and helping steer that, because that's the kind of stuff that our community would definitely use. Question. Good question. What's the future of the Fog Library? So Fog is plugin based, has drivers for just about anything and everything out there. The OpenStack Fog one is very popular, obviously. OpenStack's using a lot of shops. Right now, HP and Rackspace are rewriting the Fog plugin. They've got a public branch somewhere. I don't have the URL on my slides, but and they will be replacing the current OpenStack provisioner with a new, an updated version of it. And once that happens, we'll be able to replace Knife HP and Knife Rackspace V2 with Knife OpenStack. So we'll have the same auth endpoints and all that will collapse into a single Knife OpenStack to rule all the OpenStack deployments out there. The Rackspace one will stick around because it has Rackspace services. The Rackspace maintains, another example, Rackspace maintains Knife Rackspace. And so they actually, they add features that are exposed in their cloud through their plugin to make sure that you get that sort of stuff. But HP is mostly, like Knife HP doesn't have extensions. So it's the same thing as Knife OpenStack. And if we can collapse those into one plugin, everyone benefits. So that's the future of the Fog plugin. Question? Sure. Yep? Yep. So actually I met with SIG last week about this. Yeah. So I had a meeting with SIG about this. And so we were talking about what the lifeline would look like getting them onto Stackforge and when it starts to make sense. There's some normal use cases that need to be met there. But that's kind of what we're looking at is as you're being incubated, we need to figure out what an incubated Cookbook looks like. But the general idea would be we could bring it in as its own. So it would be, Cookbook OpenStack, I can't remember what Barbican's other name is. Yeah, Key Management. So you ended up with a Key Management Cookbook. Mumble service. Yeah. And you have a couple of your own wrapper Cookbooks that are doing similar things right this second where you're doing your own Postgres stuff. So we would wanna switch that back kind of over to the ops database and get it folded in. So we actually started that with your team. I mean we typically haven't been taking incubated projects because our focus traditionally has been stable releases, which means that we're not taking the incubated stuff. But as we started moving on to trunk, there's no reason we couldn't take those because they're usually in their own brand. They're in their own Cookbooks. They're in their own Chef GitHub repos. They're not gonna break your stuff if you don't use them. So we'd probably set up a secondary core team for y'all. And then as it got more and more adopted, more used, the community would start helping out on the work. A bunch of resources available for Knife OpenStack. Help documentation pages on it. It's up on GitHub. We manage all the pull requests and we like to work with tickets just to help track how everything works. Like I mentioned earlier, 0.10 was released last week. Other features besides the use of names everywhere instead of UUIDs. We now support availability zones. You can now, if you're using Neutron, specify the networks that you want to connect to when you create an instance, as well as the networks that you want to bootstrap when you bootstrap a box. And then actually being able to push metadata into the metadata service at node creation. So if you're like throwing tags in or credentials or something like that through Knife, that's all supported in 0.10. And that's a lot of good features around there. There are more roadmap items for Knife OpenStack. Obviously with all the, with new features, you find more bugs. So more network in your UID cleanups. I would, we talked about Knife HP, Knife Rackspace Consolidation as the OpenStack provider, it gets better. We have a common library for Knife called Knife Cloud that's coming that standardizes command line options for Knife plugins across all the ones that Chef maintains. So Knife OpenStack, Knife EC2, Knife Google, Knife Azure, they all would all, right now they all have like dash dash private network, dash dash private, dash dash private underscore network. So we're consolidating that so they all behave the same. And then another thing we will add is Travis CI support. So when you make a pull request into Knife OpenStack, it'll actually run real live Knife tests against real live OpenStack infrastructure just to see if your patches breaks the test framework. So that's coming. So Test Kitchen, Test Kitchen is another project that we have that uses OpenStack. So Test Kitchen is an integration tool for developing and testing your infrastructure by providing isolated target deployments. That's what it says on the GitHub page. What it does is when you have a cookbook that you say, hey, I support CentOS 6 or REL6 and Ubuntu 1204 and Debian 7, it'll actually spin up a VM for all the platforms that you say you support and deploy your cookbook into that VM and run whatever test that you have. And so you get real live integration testing and you're able to use different back ends for Test Kitchen. Vagrant, obviously Vagrant's really popular. So Test Kitchen has a Vagrant driver. So you can have Vagrant spin up your desktop VMs but we also have an OpenStack driver. So you can actually spin up VMs to test your infrastructure before you deploy it to your real infrastructure. And if you're building a CI pipeline, you can continuously test your infrastructure code before you actually deploy it with real live VMs. Not just mocking it out or anything like that but actual real servers and tear it down when you're done because all your tests pass, of course. Kitchen OpenStack is the driver. Test Kitchen runs off YAML. So configuring OpenStack is just a couple of settings. It's not too heinous. We will start using Test Kitchen. We will start using OpenStack to test OpenStack with Test Kitchen and actually running Tempest on top of OpenStack deployed by Chef. And possibly RefStack, which is like the new thing for end-to-end testing. Right, because that's kind of one of the things on StackForge that we're missing right this second where we have a pretty good set of unit tests that you can run on your local workstation but we don't have a great set of integration tests. So what we really want to get to is we want to, whenever you're changing one cookbook, it will actually check that cookbook out with your change and then do a Test Kitchen spin up to install that cookbook and any dependency cookbooks that it needs so you can specify a run list and a test scenario. And then you can use ServerSpec, which he mentioned earlier, which is RSpec but instead of it being mocked out like ChefSpec is, it actually runs against an existing system, a server. So if you tell it to, you know, I assert that this package is installed, it'll actually go, okay, this is an Ubuntu system, let me do a D package and grep for that package name and okay, it is installed. And then we can also do command line testing. So if you think about the Glantz cookbook or the Image Cookbook, right, you should be able to lay down Keystone, you should be able to lay down Glantz and then you should be able to go through a set of tests of, you know, do a Glantz image list, upload an image, delete an image, check metadata and make sure that the configurations you have in the cookbooks actually work. And then on top of that, you want to be able to take that one change and go back up to the whole top level and do a full end deployment with that one merge and be able to do Tempest against it, which is where we're talking about adding a Buster to Test Kitchen to be able to fire off a Tempest test against an actual installed cloud. So all of that will become part of the gating process. Yeah, testing. Yeah. So Chef Metal. Chef Metal is another new project that we recently announced. It has a great logo, so I had to throw that up there. But what Chef Metal is, is Chef uses, currently when you think about Chef, you're like, hey, I have a Chef recipe and it configures a node. It has things like packages and files and directories and users and all that kind of stuff. Chef Metal takes it up a higher level. Chef Metal provides Chef recipes for deploying infrastructure across multiple nodes. So Chef Metal actually is kind of how you do orchestration of servers. How you do orchestration of infrastructure, deploying, hey, I need to do these 10 machines, then I need to do these 10 machines, and then I need to go back to that first 10 machines and update their run list and how they talk to those other machines because something changed in my infrastructure. Oh, but since it's Chef, that behavior is idempotent. So I can actually run this multiple times and adjust the number of machines. And Chef Metal will say, oh, I have 10, but you asked for 20, let me add 10 more. And then when it gets to the next step, it says, well, things change that I depended on, let me rerun Chef on those nodes as well. Because we're building idempotency on top of idempotency that should be safe to run, we're still, it's a very new project, but people are still using it in production because they don't listen. It doesn't do teardown very well yet, so that's a caveat. But it also provides primitives for things like deploying, creating cookbooks on the fly, creating clients and nodes and roles and the things that Chef, that you would do to manage your Chef infrastructure. Chef Metal can be used to deploy Chef servers, create things on the fly and push them into Chef, deploy infrastructure on Chef. It's very meta, which is why the original name was Chef meta. But you know, as we start talking about servers, that's a better name, I guess. There's not a Pixie driver yet, but there's one in development. There are bootstrapers for many infrastructure types. For cloud, there are drivers for DigitalOcean, for EC2, there's a generic fog one that probably supports a lot of stuff. There's an open stack specific one that we use in production ourselves. Supports vagrant and vSphere for virtualization, as well as Docker and LXC and SSH. So if you have a bunch of boxes just sitting around, you can run Chef Metal across them and deploy. We gave a demo at ChefConf using Chef Metal where we had a recipe to deploy a node on EC2. We went into that node and installed Docker and created a Mongo image container, pushed, published it to a registry. Then we went back to our Metal recipe, added another instance on EC2 to run as a Docker host, ran the recipe and said, oh, all those first steps are okay. Oh, now I need to add that host. Went back, updated the recipe to create containers inside that Docker host. It runs through all the steps, checks that everything's okay, spins up the Docker images and runs Mongo from a node, managed from a node inside of EC2, deploying other infrastructure inside of EC2. One of the cool things about Chef Metal is it has the concept of a provisioner node. So this is a node that deploys infrastructure on your behalf. So you no longer have to have your workstation to deploy your infrastructure. You can actually have fully self-contained infrastructure that manages itself. It's kind of crazy. It's very, very alpha, but people use it in production. And this is what it looks like. This is just, this is from the ReadMe. It's very simple. Where you have resources for a machine, where you have a recipe and some tags and it'll go in, create it. Not listed here is where you actually specify your provider. There's a line that says like metal provider equals EC2, metal provider equals whatever. You manage those with attributes. And here we just have a number of servers equals one and then we can say one up to number of servers, go and create those machines. This demo works, it's frightening. But that's Chef Metal. So you'll be probably wanting to use that as a back end for a lot of CI pipelines eventually. That's how we think about using it. So that is the quick overview of what Chef resources available for OpenStack. Whether you're standing up OpenStack, whether you're deploying infrastructure on top of OpenStack, whether you're testing on OpenStack, I think we got it all covered. Are there any questions about those things before we start diving into the code? Question. Yeah, Chef Metal is gonna be very amazing. Anything else before we start diving into the vagrant stuff? Sure, sure. So paraphrase your question is how could we have something like Chef recipes or Chef Metal take advantage of salameter services that are exposed? So is that a fair paraphrasing? So earlier the question was are there cookbooks for OpenStack primitives like block storage or salameter? Yes, that's how we could do it. The nice thing about Chef Metal is this is just a Chef recipe. I could take these Metal recipes and I could actually have a MySQL cookbook that spins up its own clusters. And all the resources that I have in a standard recipe are available to Chef Metal as well. So if I'm writing an OpenStack cookbook that supports OpenStack, that provides resources for dealing with OpenStack infrastructure like salameter resources that expose hooks, I could roll those right into my recipes where I make API calls and I get back, hey, give me a salameter, what's the value of the sky? Oh, the value of the sky is blue. That means we need five web servers and so our variable here would change and so as we run our Chef Metal recipes or our regular recipes, they dynamically adjust what sort of infrastructure they're deploying. I mean, that's the beauty of Chef is that because it's written in Ruby, we can do dynamic infrastructure like that and tie into APIs and wrap those APIs in easy to use helpers. So yeah, I'd be happy to help you work on that. So, any other questions? Okay, well let's dive into vagrant. So the instructions, if you want to follow along at home or kill the Wi-Fi here, are there. Bitly, ATL Chef, that's just a read me of what we're gonna show and how we got there. Inside those instructions are, hey, you will need to install the Chef DK which is like a 200 meg download. You will need to install vagrant which is a 500 meg download and virtual box which is an 800 meg download. You're gonna kill the Wi-Fi. The plan for the walkthrough, we talked about the setup. We're gonna talk about the tools that we're using, how they're all tied into this. We're gonna take a look at the vagrant file. We're driving this with vagrant, if you're not familiar, we'll try to cover those sorts of things. We'll look at the environment that vagrant is using to run this and then kind of the roles that we actually use to deploy this infrastructure and how the roles in the OpenStackChef repo are organized. They're very simple and so you end up actually using a lot of them. How a typical cookbook is organized we'll probably look at the glance cookbook just because it's concise. It doesn't do a whole lot and everyone can kind of wrap their heads around what glance does and then actually log into the dashboard because this actually works and then run a knife against it if it all works. So the tools that are used. One of the tools that we maintain is called Bento. Bento is a front end for Packer. Packer is an image builder from HashiCorp, the guys who make vagrant. Packer, you give it a JSON file and it spits out just enough operating system images of targeted to the platforms you want. So if you need to build the same image to use on VMware and OpenStack and Amazon, Packer will take that JSON file and spit those formats out for you. Bento is our front end for that for doing really stripped down operating systems. So if you need a stripped down Ubuntu, which is what we're gonna be using that is pretty much nothing on it. It doesn't even have Chef on it. We put those, that's what Bento is for. So it's just a set of templates. If you used to use Veewee, these projects have replaced them and we're working with Patrick Dubois who's the guy behind Veewee on Bento. We're gonna be using Chef Zero. So Chef Zero is a fairly new tool for Chef. It's an in-memory Chef server that it's fast because it's in memory. It has no off. It does have persistence, which is weird. But what it does is rather than use Chef Solo, which is a good installer, Chef Zero gives you a Chef server that you can upload cookbooks to, you can search against, you can upload all your roles to, and it's great for testing because it's small and fast and it just spins it up. You run your Chef infrastructure against it and then when it's done, it's gone because it was in memory. There's no authorization. You can't do more than about 10 nodes in it. It's a Ruby Sinatra app. It's not for production, but it's perfect for testing. So with Vagrant, we throw up a Chef Zero to actually test against so we don't have to use a full-blown Chef server. And then we use Berkshelf. And Berkshelf, if you're not familiar with it, it's pretty much the de facto standard tool in the Chef community for how we manage cookbook dependencies. So if I have a lot of cookbooks, like OpenStack has a lot of cookbooks, it sorts out all the dependencies, all the versions, and where you would actually get those cookbooks from, whether you're pulling them from the Chef community site or if you're pulling them from a GitHub repo. So that's what Berkshelf's for. And we use it just to keep straight all of the dependencies on cookbooks that we use. So if you're not familiar with those, you will be eventually. So the Vagrant file, highlights of the Vagrant file. We're using two plugins. We use Vagrant Chef Zero. So Vagrant Chef Zero spins up a Chef Zero instance, and then as it spins up the Vagrant instance it points it at that Chef server. If you're familiar with Vagrant, there are drivers for Chef and Chef Solo built in. Vagrant Chef Zero takes the Chef one and just points it to a Chef Zero deployment. And then Vagrant Omnibus pulls down the Omnibus Chef client and makes sure that you have the version that you specified. So let's take a quick look at that. Oh, that's nice and small. This is in Stackforge, OpenStack Chef repo. Okay, so this file is called the Vagrant file, Vagrant file-aio for all-in-one-nova. This is fairly boilerplate Vagrant syntax. You'll require one one or later. So we're using the Vagrant from HashiCorp. And they're the two plugins that we use. And then we're gonna configure an instance. Here we see Chef Zero is enabled. We're using the repo path. So it actually just looks in the Chef repo and says, where are the cookbooks? Oh, here they are. Where are my roles? Where are my environments? We can specify which version of Chef we're gonna use. In this case, we just used the latest. If you needed, for whatever reasons, perhaps your infrastructure is only using 11.10 or 11.4 or some older version. You could hard code that. And then standard Vagrant configuration as we create a private network because we're actually gonna spin up the OpenStack instance to talk to a network. And then here's the environment that we use. Vagrant, AIO, NOVA. And then the run list that we use. So the Chef run list, this actually gets deployed on the Vagrant instance. The role is all in one compute. And we add the OS image upload. So Vagrant will run the glance upload recipe. So it'll put the Seros image on here. So we can actually deploy an image on our OpenStack. We need a slightly beefier virtual box. So two CPUs and two gigs of RAM. And then we have a few Ubuntu 1204 settings. Here we see our Chef provision in the earliest box. So this is just our stripped down OpenStack, our stripped down Ubuntu 1204 image. We port forward a whole bunch of extra ports. So we can actually log in to the admin console. We can expose the API endpoints. We can access the Chef zero. Yeah, access Chef zero. Those are all documented there. Get your identity points. And then there we point the Chef client to point to the zero instance. The other thing in this file is, there's CentOS in here as well. So we can see all the CentOS settings are similar. And then what this actually looks like when it runs. So when we kick off, I can actually switch back to mine. So when it actually runs, here we are starting up our Vagrant up. We see it importing the base box. I didn't have to download it. I already downloaded it. That'd be another 200 mags to kill the wifi here. Actually, it goes and sets up the box and it kicks off Chef zero. So we see, hey, we're gonna load the cookbooks from .cookbooks. So we did a Birx vendor to upload the cookbooks into the directory. It looks in that directory and says, oh, I got a few cookbooks to download. And then it downloads, it just uploads them all into memory. Reads them right off the file system. It reads in all the environment files. So the Vagrant ones that are available goes and uploads all the roles and there are a few. And then it does our port forwards. We see, and here's the omnibus kickoff where it's gonna go and get the latest Chef client. 11, 12, four. Goes and downloads that. Hey, Vagrant's fun to watch. And then installs Chef. And then installs Chef. There's new, thanks to Heartbleed, we now have some SSL validation for you and it complains about that because there's no SSL here on zero. And then it kicks off the Chef client. So it actually says, hey, you wanted an all-in-one OpenStack. I'm gonna do that. So let's take a look at what that looks like. Any questions about Vagrant? Hopefully you've seen Vagrant by now and you've had a chance to use it. So the environment. So one of the lines in our Vagrant file was which, what's going on in the environment that we're going to use. So when we were talking about the cookbooks, we said, hey, these are all driven by attributes. The attributes are not, they are saying defaults inside the cookbooks, but you can override those externally and the place most people do that is within an environment file. So I could have an OpenStack, a QA lab, a production lab, a developer lab. They could all use the exact same cookbooks but the settings that, the differences between them would be contained in the environment. And so let's take a quick look at the environment file. So we've got Neutron and Nova. I spun up, oh, that's tiny. Yeah, it's a JSON file. It's not super exciting, but here are the attributes that we actually set. Developer mode is true. Yeah, so developer mode true lets us use well-known username and passwords instead of randomly generated, which is what the cookbooks will do if you do not have that turned on. So you can define everything inside of a data bag. So you can pre-encrypt all your passwords and they'll use those. Or if you don't have anything, it'll automatically generate them for you and throw them into the day bag. Developer mode true will turn that off. The endpoints is set to all interfaces. So by default, right the second everything binds to local host, but because we are exposing the identity endpoints through the port forwards and vagrant because we want to allow you to be able to do, you know, a Nova from outside of your vagrant against your vagrant. So we have to bind to one, two, three. You have to let your catalog show as 127.0.0.1 because that's what your vagrant port forwards are gonna hit, but you want the keystone instances inside to be listening all interfaces because VirtualBox creates a wonderful NAT interface as eth0 that you need to be bound to to catch all of your port forwards. So that's what that line is. Image upload true is allowing you to define if you want to once Glance is installed if you want to pull in any images. The next array will actually tell you what images you want and then the next line tells you the path for them. So you can put in a whole bunch of stock images if you happen to have your own platform team providing you images that you deploy all the time. You can build them into the array and then you can choose which ones you want to turn on and off as you build a cloud. The next sections are network settings for Nova. So what is your public interface? In this case, this is because of the way vagrant does its networking. It's a tad bit wonky. Your eth0 is actually a special NAT interface. Eth1 was the network that you saw us create inside of the vagrant file. So we're able to tell it to use that as its public and we're setting service type to be Nova so that we're running Nova networking instead of Neutron. RAM allocation ratio, we set it a little bit over because this is testing and you want to be able to fire up a couple of micro instances and that hits your RAM allocation ratio and Nova will get complaining at you if you don't set this right. Obviously you're using QMU because we're doing vert, invert, invert inception. And then we just define a generic public network so that instances whenever they boot, get this network. And if we look at the vagrant all in one for Neutron, it's not that different. No, it's mostly the same. Yeah. Except for you have the open V-switch settings and you have a little bit different networking settings, service type network and we don't define a network for you. Yeah, so you'll have to actually do that. So that's what our network looks like or our environment looks like. And of course, if you were rolling this out to real production, things like the IP addresses, you might use VIPs in places and store those in your environment. So that's probably one of the more complex patterns that's in the cookbooks right this second is there's a split between endpoints and endpoint binds. So this kind of comes from the concept of being able to load balance it. A lot of times if you want to have two, you might want to say for these two keystone instances I want you to bind to ETH zero on these two boxes or you might want to hard set the IPs so that they bind to a specific IP on the box. But you want your service catalog to have an entirely different IP for the endpoint because let's say you're running a VIP on a load balancer and distributing traffic, you don't actually want either one of the two IP addresses that the boxes are binding to, you want the VIP. And so we have URI patterns for every service where you're able to delineate between I want the endpoint to look like this which is IP address port paths. And then whenever I bind, I actually want it to bind to these interfaces or these IPs so that way you can actually be able to model the load balance scenarios very well. But that one, whenever you look through the cookbooks it's a little bit weird looking at first until you kind of conceptualize that concept. So roles, there's a bit of contention in the Chef community around the use of roles because they're not versioned. And it's possible to update a role and affect multiple pieces of infrastructure. One of the things we've talked about for Chef 12 is there may be versioned roles or something better than versioned roles. And so some people do not use roles. The usage of roles by us is strictly for run list. We don't ever put attributes inside of our roles. But what we do is we do run list composition by roles. And so all in one compute is the one that we used for this to kick this thing off. And all in one compute calls two other roles. Compute single controller and compute worker. So as we start, you can see these patterns emerge of if we were doing a one plus in, a single controller node in compute nodes, well we would just put the single controller role in one box and everyone else would be a compute worker. Since we were doing all in one, they end up on the same box. If we look at the OS compute single controller, it gets Harry, dot dot dot means I've got three pages of roles. It has a base role and this is like Oliver Opensack instances have this. Then it installs the database. Ops database is going to look at an attribute for the actual database that we use. So Postgres or MySQL. And then it will call Ops database Opensack DB to create the schemas that we're going to be using. And that actually goes and says, well which services are in my run list? Let me go and install all of those schemas. So everybody who uses MySQL would get their schema installed on this box. That can be further be broken apart. So you could run multiple MySQLs to have different databases providing the different services. Most people don't do that. And this is where that Chef repo, the Ops code or the Opensack Chef repo is really kind of an example. It's not necessarily meant to be the thing that you should run. Role spaghetti happens to everyone. You start kind of going down this path and then all of a sudden you have 1200 roles. We've done it before. This is the way it always happens. So we've put together the conceptual components that you might want to put together and then that way you have a reference for what recipes make up the conceptual component. So each service and or endpoint has its own role. That's more than likely the way that you would end up if you were running this in production, you would either take that in its run lists and recompose them in the way that you want to organize them or you would take those two and recompose them in that second level that fits the way that you want to deploy. But once you do that, like you're gonna be in this exact same scenario where you have meta, meta, meta, meta, meta roles. And at the very top you're inheriting 15 levels of instruction. You would end up flattening a lot into the common use case deployment. So you would probably end up with, hey, this is a compute worker, this is a storage worker. I think that's the way most people tend to deploy this is they go, I have these conceptual buckets that I drop everything into and then I go and look at the example roles, figure out what makes that conceptual bucket, make one role for myself that's a whole bunch of recipes and then I only have like 12. Yeah, we have a lot. So yeah, we install the database, we install whatever messaging service you've chosen. Rabbit's the default, but Cupid works. Open stack identity, so that goes and puts glance on the box, or keystone and then OS image is glance, OS network if we're doing neutron. And the role looks at the attribute and if you are using Nova network, it's like oh, I'm gonna call over to the compute cookbook rather than go and try to do neutron when I specified Nova and then it keeps going. We're gonna do the compute setup, the compute conductor, scheduler, API storage, block storage, the certificates, VNC, and then the dashboard and the compute worker is really simple, it's just hey, I got a base role and I'm gonna be a compute worker. But that gets rolled into a single mode and when we run that, here we see the run list is expanded to, there's an app cacher client we added in case we're using caching, but there's all in one compute and the OS image upload that we got and then that expands, here's our run list. It's a little ridiculous, but open stack on a single box is a little ridiculous. And so it kicks off the Chef Client run and you see it loading in the cookbooks, several pages of pulling those down from Chef Zero, which is nice and fast. We got a few recipes here. Almost there. So anybody know any good jokes? Okay. A lot? How long is this output? 743 lines? Okay, so we're almost there. Okay, so here's where it actually starts doing work. Pulling in Keystone URLs, it goes and looks through the environment and all the attributes that were set and puts together where are the end points that we're gonna do. So this is in our Chef phase, this is actually compiling the recipes and running the Ruby stages. Getting all of our attributes in place and then actually going and starting to do, I turned off WordWrap, it's hard to read. And then it's just gonna start running and running and running. You don't wanna actually watch this happen. But you know, it goes and goes and goes hey, we get to Apache, that's cool. And now we're doing, still doing Apache, Nova Compute. Levert been restarted, restarting all of our services at the end. And we're done. And we're done. Chef run complete in 637 seconds. 10 minutes. And then I was able to vagrant SSH into the box. You know, I did that this morning. It works. It takes about 10 minutes to run a full all in one on a fast laptop with SSDs. But it works. One of, so that's what it looks like. But if we want to drill down, and then the dashboard actually comes up on local host 8443, session timed out there. And the password is admin, admin. Unless you said it differently. Oh, unless you said a different one. This is, you know, so I'm actually running vagrant and I was able to just go into it. Hey, I'll show you what that output looked like. Vagrant output, there we go. Sorry. And this is all in the script that I linked to earlier, the Bitly ATL chef. So we don't wanna run through all this. But, you know, I log into the vagrant image. I sudo up, I source my OpenRC. I list all my Nova services. There they all are. You know, I'll run in on 127001. I list my hypervisor. There it is, Ubuntu 1204. I don't have quantum agents, because I'm running Nova. I do a Nova image list. And we can see we uploaded the Cirrus image during the call, or during the run. And then I do a Nova boot test one, image Cirrus flavor one with the poll. And when it's done, boom, 100% complete. Nova list, there's our instance. Nova show, you can see, hey, all the fun stats. SSH Cirrus at 192.168.102. And it works. You can go run this today. This is, and then when we're done, I can say knife, node, list. And I changed my IP address so it won't work anymore. But this is cool. So, you know, the dashboard works. We can click around on that. You can write out a file on your file system. I call mine zero.rb, it's a Ruby config file. Then I have the, this was the IP address in my hotel for my laptop. If I put port 4002, this is the Chef zero that's running. I have to make up a node name. You, it requires you to have a node name. I have to point it at a client key. It doesn't actually, it can be like, you know, a random file. It doesn't actually matter. Because Chef zero has no authentication. So it just, Chef, Knife wants it, but Chef zero doesn't care. I put my open stack creds in there. And then I can actually say, Knife node list, point it at that zero rb file, and it'll show me the Ubuntu VM that spun up, and I can see all the OHI data on it. Cause it's persisted it to a Chef server. Just not like, you know, a persistent Chef server. And I can actually say, Knife open stack commands against the open stack that's running inside a vagrant from my workstation. So it's kinda cool. It's broken right now, cause my network's changed multiple times, and I don't know my IP addresses. But it does work. And so this allows you to test all those Knife commands against vagrant, or all the Knife open stack commands against vagrant when you don't have a real open stack deployment. Which is how I do a lot of the Knife open stack work. Cause our open stack deployment is old, cause it works. So I think that's, we can actually, you know, it's 12, 20? Questions. Yeah, we can either go questions or we can dive into a cookbook if you want to like peel back the covers a little more. What would people like to see, or is everybody hungry and just wants to go to lunch? This is a good point. All right, there's a lunch vote. Okay, well thanks for coming. Chef is, we're at the Blue Box booth today if you want to stop by and chat some more. And of course, it's community projects, so please feel free to join us. Contributions with him.