 Hello, I'm Cody Harrius from Public Labs Day. I am going to be talking about our efforts to get Puppet into the larger OpenStack infrastructure and ecosystem. I was also going to have a demo of building OpenStack. But as of this morning, a whole bunch of Python packages got updated on Ubuntu, and now my demo is blowing up. So we'll see if it comes up, but I'm not too positive that it will. So while it finishes building, just a quick overview of what Puppet is. Our platform is traditionally a master agent system where we have a whole bunch of agents out on some nodes that collect metadata and are able to publish those. That's a tool called Factor. And we all kind of tied back to this Puppet Master. And we have a console, Puppet Modules. There's over 1,000 modules on our Puppet Forge now. And downloads are increasing every day as well. So that ecosystem is kind of really blown up lately. And we're kind of nice to see that the community are taking off with all the modules. So how Puppet works, you define your infrastructure in a sense that you're actually trying to describe what the in-state's going to be. You're not imperatively trying to develop a set of actions that must happen for something to actually be running. You're actually trying to say that you want an Apache server, and you should ensure that it looks this way. And so that's the part of the definition. And we have a basic declarative DSL that does that process. After that, we always encourage people. Puppet has a full-fledged simulation mode. It's built into the actual model that the resource model we use. It's all inside the Type and Provider API. We can check to see what's actually going to change and generate events on those, and actually report on them as well. After that, of course, you just run an enforcement. It makes all your changes. It's great if you can actually get this to actually happen all in one run. It takes a little bit of experience. But there is a dependency system in order to make things not have to be ran multiple times. And that's really, at the end of the day, it's Puppet is supposed to be idempotent. And so the goal is to make sure that you only need to run once. So that you don't have to worry about the previous state in order to get to the next state. And like I said, all these events are all kind of cached up and sent off to any type of reporting server that you want. It's generate, predominantly ends up being an HTTP post that a lot of people do. But you can produce any amount of post processors for this data. Generate tickets and emails on them. It's fairly straightforward. If you're ever looking for a way to process this data, look up Jane's Turnbull. Anyone in the public community kind of knows who he is. A lot of people in the just open source in general. He's written a lot of report processors because they're just really simple. They're all over his blog. They're all different kinds of use cases for him. So as far as the data flow in Puppet goes, the node generates a set of facts. It's then going to send those facts off to a Puppet master which generates a dynamic catalog. That catalog is a set of JSON that has then shipped down to the agent. So the agent actually only ever gets the information that it needs in order to enact the state on its specific node. So it allows us to actually manage our infrastructure much more the way that you would manage a software application. So we can take a certain set of code and actually migrate it through different states. And we can actually look at that and iterate on it and actually go through an actual development process for actual infrastructure. And so it then doubles also that you can have different environments that are all as close as possible if not exactly the same through development cycles for developers as well. So if someone is producing an application, you can certify that that machine will look the same all the way to production because of the declarative state and the way that you've described things using Puppet. So how does this all relate to OpenStack? Puppet manages OpenStack. And then on top of that, Puppet can actually deploy VMs into OpenStack plus other cloud providers. And then once that VM is actually deployed, it's kind of where it originally started, Puppet, was managing that application layer. So we go from bare metal to hypervisor to deploying virtual machine all the way to actually ending up deploying the application on the machine as well. So these modules that we developed, they're no longer a Puppet Labs project. We're actually quite proud of this. They are an OpenStack project. So we have Dan Bote, who started working in OpenStack for us about a year and a half ago and just lived OpenStack for the last year and a half, put a lot of effort into actually getting our modules, which we started, kind of graduated into an OpenStack proper project. And now they're part of the same Garrett and Jenkins CI system that OpenStack itself runs through. So this was done with a partnership between, of course, us and the HP infrastructure OpenStack team. It's been really great because we are one of the very few configuration management systems for developing and building OpenStack that's actually on Stackforge, which Stackforge on GitHub is the place that all things that go through the OpenStack infrastructure Jenkins and Git workflow end up here on mirrored on Stackforge. So you'll find a lot of stuff there. I've highlighted just the Puppet OpenStack one up there, which is the one that encompasses all the other ones. So there's actually sub modules for Cender, Nova, Glantz, Horizon, and they're all just kind of built into this one big Puppet OpenStack module. So because they're actually now an OpenStack project, and we've released kind of most ownership of it, you'll find tickets and everything up on the Puppet OpenStack launchpad page. That's where all kind of blue prints, bugs are posted. So it is also if you go searching down through Stackforge, you're going to find PackStack, which is now the basis for RDO RedHots deployment of OpenStack. That's all downstream to our Puppet modules and also Mirantis plus a couple other OpenStack groups are based on those as well. The other one up there is largely just it was a development environment used so that we could quickly spin up vagrant boxes based on the OpenStack work. So if you actually want to bring up an OpenStack environment in about 10 minutes, only because vagrant isn't very good at being parallelized, that's two vagrant commands and you'll get an OpenStack controller and a compute node. It's fairly straightforward. It is what I was hoping would actually function. All right, there we go. Where's my mouse? OK, so everyone's seen the horizon page. This is what comes up from just building the OpenStack controller. Fairly straightforward. OK, I'm going to go ahead and let that continue. So all the various modules that are available via Stackforge, these are also all going to be on PuppetLabs. Forge.PuppetLabs.com, to get going, the OpenStack module itself is what wraps all this with a whole bunch of default data so you can actually not have to think about a lot about getting a default installation up. So there's a lot of work getting into Stackforge. We've had to change our entire workflow. It's actually going to be much better for the Puppet module community as now we can actually much easier track trunk for OpenStack. And right now we're about just under a release behind. The upstream modules have one bug in Grizzly's quantum modules, but they've all been fixed by the downstream folks. So RDO, which ships Grizzly based on these modules, has already fixed that problem. So we would like to be able so that you can actually truly develop on these modules via trunk. So they need to move a bit faster. Being in the OpenStack community and an OpenStack project will make that possible. I've talked a little fast, about three minutes fast. We'll see if my compute node actually comes up. But anyways, a more thorough kind of fall along hands on is going to be actually done by Dan tomorrow morning early 9 o'clock, I know. But getting started and deploying OpenStack via Puppet is going to be tomorrow morning. It's going to use the vagrant OpenStack stuff that I tried to get up during this quick 15 minutes. So come prepared with a laptop. Yeah, and Wi-Fi just ain't going to let me do it. So thank you. And I'll see you tomorrow, hopefully.