 Okay All right We're gonna go ahead and get started. Thanks for showing up this morning. I guess a few people had a late night last night I know I did So my name is Matt Ray, this is Justin Shepard Just the first things to get started This is a hands-on workshop, but you are not expected to actually You can do everything we cover in the demo if you want we have mirrors you can download all the pieces you can install the packages If you follow the instructions, you can do the exact same demo that we're going to do you do right now if you want probably better if we all paid attention and You can just download it afterwards and run it at your leisure. It's all on github. It's all on the mirrors But yeah, feel free to kill the hotel wireless while you're here Because that's why that's why we packaged everything up for you on the the wireless that we brought and we threw up mirrors as well, but You know go download gigabytes and gigabytes Let's see if we can kill it for people. Yeah So what what we're gonna do today is we're going to you know, go ahead and download the the instructions there So you can follow along what's what's happening, but we're gonna provide a background about the project about what we've been doing And then we'll go ahead and dive into the cookbooks the code You know talk about all the different pieces of what the demo actually is and show you know, what's going on with all this Fun stuff we have going with chef and open stack. Is there anyone here already? Who's not familiar with chef? Okay Then I will give a quick reset on on chef. I don't I think I have too many slides on that But I just quick introduction. My name is Matt Ray. I work at ops code. We are the company that makes chef My title is cloud integrations lead. This is I've been at all the open stack summits and There's you know email github IRC Twitter all that stuff With me holding the laptop is mr. Justin Shepherd I'm private cloud architect at rackspace Part of the RCB ops team that has been doing the chef cookbooks for a long long time one point we Had started doing it and everyone forks from us not because of technical merit, but more because we existed So then Matt and a bunch of the other involved parties Which we'll get to have kind of come back together and take the best of all the world that produced the kind of Conuncle cookbooks. That's a good start Uh Okay, so rather than dive immediately into the chef for open stack stuff for those of you are unfamiliar with chef chef is an open source configuration management and automation framework it provides the ability to manage large numbers of machines it It's built on the idea of Infrastructure's code this means that everything that you do to a machine can be traced back to source code So you can You know the packages as you install the service they talk to how all these things work together It's tracking source control. So if you need to Move your infrastructure from one location to another if you need to auto-scale if you need to Recover broken missing machines that go down because you're running on an unstable cloud Chef is really good in that sort of situation. We have support for just about every platform You know Linux Windows Solaris AI X OS X and and on and on and It's patchy licensed so people take it embed it and lots of other products That's the the short overview of chef. It's written in Ruby The client is written in Ruby. It does not have a configuration language of its own It actually just extends Ruby. So the nice advantage of that is You have chef provides primitives and resources for managing things like packages And we're gonna see we're gonna see a lot of recipes, which are how chef configures machines but The advantage of being in Ruby is if you need to do something more dynamic if you need to Calculate something access the library rubies a really great language because it already has support for interacting with lots of things Already it has a huge community very vibrant open source ecosystem. People are doing just about everything with it And that's exciting And a good way So, you know feel free to ask questions as we're going We will be diving into some recipes as we go so you can see what it looks like if you're unfamiliar with it And you know, I'll be trying to explain some of the concepts as we go So a quick overview of the chef for OpenStack project So chef for OpenStack is a project. It is not a product per se. There's nobody who says, you know, hey, you know call up ops code And we will sell it to you What will happen is you call up ops code and say have you talked to somebody to do OpenStack for you? Because we're the company that makes chef. We're not an open-stack company But a lot of companies that are using chef are doing OpenStack. So HP's public cloud IBM smart cloud rack space private cloud. These are all built using chef There are a lot of other projects crowbar has chef embedded in it I'm sure I'm forgetting a couple others, but the the idea really is chef is a really great way to Put open stack together because it's complicated OpenStack is not simple to configure. It's not simple to manage So what we did was reformed a community around the automated deployment and management of open stack, you know Setting up and configuring an open stack should not be your company's secret sauce your secret sauce should be your support Or the value add you put on top of open stack So we formed this project to reduce the fragmentation and increase collaboration The next slide. I'll show you some of the people who are currently involved Okay, well, we have an IRC channel. We have a mailing list. We have Twitter account, you know community kind of stuff But here's some of the company's currently involved AT&T is using these cookbooks in production and there are multiple data centers several thousand machines AT&T is using them. Dell is going to be contributing back to these. They've used them in the past You know as just to mention, there's a kind of a genealogy of the cookbooks have been branched and forked and merged And you know a lot of people have used these cookbooks over the years They actually got the start at Anso labs with the bear release. So it kind of goes back pretty far dream host is using these Gap is now they're using Rackspace private cloud HP is using, you know branches of these hub spots using these in production IBM is using my fork of these Korea telecom is using these in production Opsco is using these in production Rackspace is using these production and Sousa is building tools with us as well for their Open stack distribution and there's even more people if you go through the get history, you'll find some interesting people So that's currently who's involved is a very vibrant ecosystem a lot of a lot of different players Getting started on the technical side the requirements that we have for our project We are using chef 11. That's the current stable release We try to stay pretty on top of all the latest features. This allows us to you know Loves me as an ops code employee to make sure we're kicking the tires on the rough edges of chef And to make sure that the the project actually takes advantage of all the latest features We're using Ruby one nine Chef does support Ruby one eight seven, but we don't want to go there because that's been into life But the Ruby community even though lots of distributions are still shipping it We use food critic and chef spec for basic testing. There's a lot of other testing that's there That's a lot of testing that's there and a lot more is coming We use if you're familiar with chef We are using the idea of attribute driven Environments rather than putting attributes in our roles or other places. We try to keep everything at the environment level so we can So if you're not using Environments perhaps like crowbar you can actually push you can inject attributes Other ways, but we try to keep them a nice separation of the Data from the source And that's where the idea is a chef is as you build these cookbooks You can figure them with attributes from the outside so they behave like libraries And so these have become you know libraries for open-stack We keep the platform logic in our attribute files. So this means inside of our recipes They're not case statements that say, you know if we're in Red Hat do this if we're on Susa do this If we're in Debbie and do that put that in the attributes files to hide it away make the cookbooks a little simpler Currently we're only using packages from the distros Except where we're not and I say except where we're not because if you're familiar with grizzly. There's a lot of broken pieces DNS mask open v-switch. These are built from source And you know this will change in the future Keeps changing Swift off swift off. Yeah, so there are definitely other pieces that are not distro packages And there's a couple of patches in place as well. Yeah Packages only. Yeah, but it's still packages mostly So Stackforge Stackforge is the official open-stack place to put things that are not official open-stack projects so We have cookbooks on Stackforge the nice thing about being on Stackforge is you get to use the open-stack infrastructure for Continuous integration for the reviews The open-stack clas so you know that anything that gets committed to Stackforge It's good to go for however. You want to use your open-stack projects. Oh, and that's important till you know the legal people So github.com slash Stackforge cookbook dash open-stack dash and then we have cookbooks for block storage Common compute dashboard identity image metering network object storage and orchestration. So What's currently there is grizzly? You know that metering and orchestration are there Orchestration is empty. Yeah, you know, I know that Not gonna say their name that somebody's working on on the orchestration cookbook, but since they haven't committed I'm not gonna out them. There is metering work that is is in there Obviously, these are gonna come online with Havana, but the cookbooks are already there and then we have operational support cookbooks So these are reference implementations for how to configure Messaging or your database note that they don't say ops my sequel or ops rabbit MQ the idea is that these cookbooks are wrappers for the the Databases or messaging systems that you want to use under the covers So what we try to do is let you set attributes and say hey my open-stack database is my sequel my open-stack database is DB2 or postgres or you know, whatever and But you just use the ops database which will call to the right cookbooks Which allows us to get from very modular and support lots of different configurations And for messaging same thing, you know rabbit cuban, what have you? For deploying this stuff. So we have a chef repository for deploying grizzly Get hub.com stack forage open stack chef repo this provides a reference examples of the environments and the roles for how to set this up so Well, this is what we're actually using today. We're using a fork of this today. That's been cleaned up for the demo But it's a fork of this So it has the example all in one deployment that we're using for with vagrant today This is of course gated by review open stack org and more examples are coming more reference examples of are coming of You know different architectures for n plus one like you know single controller with in compute nodes or ha controller Plus in compute nodes plus block and object storage, you know different permutations. They'll all be in this repository And all gated. Yes So so when you use review open stack org you can have tests that run on the code that people submit and so we actually have We have tests that run, you know against the submissions So you know that hey this patch may break these things and so the level of testing is continuing to increase daily And so what happens in the the chef repository is we actually use a tool called spice weasel That validates the roles the environments the cookbooks the run lists that you say you're going to have it actually checks to It actually checks that those files exist, you know, what a crazy idea And it catches bugs and that's that's the idea of gating and it and the cookbooks We actually do unit and functional testing and that is going to continue to increase with more and more vigorous testing So we are providing reference implementations this is We have deployment examples in the documentation for the all-in-one compute which is our vagrant box You know a single box you stand it up. Everything is on it, you know, you have Nova on a box That's what we're doing today The single controller plus in compute very common pattern and small deployments, you know You got ten boxes. Hey, one of them is controller nine of them are doing compute, you know run a hundred VMs That's good to go a more examples are coming So we'll just continue to iterate over this as we go as we support more and more different architectures and deployments We will be providing example h8 configurations. We will not be following the the grizzly Havana H8 documentation You want to say a little more about the yeah So that's the the like Castexo gave a talk on it where they're doing the core of sync And pacemaker type of stuff We're gonna be going a lot more with the keep alive method. So we'll have Scale out on the API services We'll probably end up with a couple of my sequel implementations Something like a master master replication master slave replication Galera Or some of the ones that people are starting to contribute. So speaking back to having the ability to do different modulars For the clustering on the Message bus it's gonna depend on the implementation underneath. So there will be like a rabbit clustering Zero MQ. I'm not entirely sure what would be there and or cupid. Yeah, we'll probably be a coral sink No, we're not gonna use pacemaker unless somebody contributes pacemaker Did no one has It's open source So you can as long as whatever you contribute does not break other people's stuff and it's worked really well that yes If you want to write a pacemaker core sync implementation, we will happily take it. No, no, it is not because of that operationally Pacemaker is not super easily to automate So a lot of this is coming back from people that are running it in production. Yeah, it is the default and Pacemaker is not not very easy to HAFI or automate Sure, sure if they provide if they provide the implementation will take it I'm just saying I know rack space and AT&T and IBM are not going down that route because that That deployment architecture also does not scale past, you know hundred nodes or so And the people who are deploying it like AT&T and IBM and rack space are definitely well over a hundred nodes Yeah, so it's not that we're blocking that from coming in if anyone wants to contribute it We're happy to accept it. It's just that the people that happen to be running in production right this second all have kind of settled on a Very similar architecture and we're all going to be contributing that one back instead of going off and building another one Yeah, we definitely have a big umbrella approach our big tent approach So if you have an alternate implementation, it's really easy to wire these up different ways They're very very modular, which is interesting Because you can say well, I'm gonna have you know object storage, but not block storage. I'm gonna have you know, I'm gonna run with Any sort of different architecture right now we only have a few basics, but With the involvement of IBM it's going very wide the architectures were supporting Operational support is outside the scope of this repository. So we're not managing your logging your monitoring Or your hardware provisioning those are very opinionated fields that have many many many solutions So they don't really belong in Stackforge. So people are using these with You know from the provisioning side, you know, you have crowbar. You have xcat. You have cobbler. You have razor You know, I have a tool called pixie dust. There's lots of different implementations of provisioning for monitoring. There's Nagios There's Sinsu. There's graphite. There's Xenos Xenos. There's you know, all sorts of stuff for logging. There's you know log stash There's syslog. You know, it just goes on and on. They're not in this repository You can find example of those things outside and and the docs will probably point you that way But we'll try to keep that out because that's Too much stuff in one repo Docsopscode.com slash open stack HTML. This is official Opscode documentation creative commons licensed. It's on github You know no CLA required to contribute These get generated fairly frequently What is there? Example architectures deployment prerequisites installation docs how to use these as a developer How to contribute there is documentation in the readme's Readme's are not a great way to document something large and complex across multiple repositories so This is over here. You're welcome to contribute. We love additional examples and The example deployments that are there are mine You know, I'm documenting my small lab of five machines and I'm documenting ops codes deployment of 30 boxes with you know a couple hundred VMs Just so you can follow along from home I've been told that there will be additional documents provided for thousands of machines looking forward to that So documentation always the best part of using open source and again the example deployments that are there are The vagrant deployment we're doing today The developer lab of one plus n boxes, you know, that's my lab is the consumer grade hardware That's code for cheap and then ops code stuff, which is enterprise enterprise grade stuff and So Havana will probably be branched like next week So this is the current grizzly status the the repositories that they're It currently working on a boom to 1204 Probably 13 to 4 1310, but only testing with 1204 open Suso 12 3 Slez 11 There is some real support, but I hesitate to put it on here because I'm not testing it yet Currently for the databases, it's my sequel and sequel light is there for testing purposes for messaging Rabbit MQ on the compute side KVM LXC QMU On the network side, there's no the networking and there's quantum with open v-switch. These are known to work block storage LVM Swift for the object storage dashboard. You can use a patch of your engine access your back end. That's today 1304 was working and I had been working on it because I thought I was gonna be using that in an ops codes deployment And then they said a total force fine so I stopped working on 1304 and we're mostly sticking with the LTS releases for sanity, you know, because they move quickly and LTS is at least a little more stable. So we'll be hitting 1404. Yeah, and we'll definitely be going to 1404 You know, we won't take grizzly there, but you know, we will stick with the LTS releases as you see on the next slide This is the Stackforge roadmap We've had discussions about branching for Havana I think it's been submitted up to the you know, the masters of Stackforge to branch our stuff for us I don't think we can do it ourselves The current master branch will be renamed to grizzly and master will become Havana The metering and orchestration cookbooks are already there and so they will You know become officially part of the deployment There is about to be a very large influx of contributors The current repo has contributors from all those companies I listed But these this repository is knock on wood about to be adopted by Rackspace IBM and Dell and SUSE. So there's about to be a you know force multiplier of people contributing All of them already have done Havana cookbooks. So the you know Havana will move rather quickly What what's More interesting is we will be branching for Icehouse You know IBM would like to branch in December So we will start tracking trunk. Yes So so we have The question was how will we track the different releases? And so in in get there will be a branch called grizzly the cookbooks in the different branches the the Versioning is tracking the current open-stack release. So grizzly was the seventh release of open-stack So grizzly cookbooks start with seven Havana cookbooks start with eight Icehouse will start with nine Using the tools like Berkshelf. It allows you to pin a Berkshelf and spice we will allow you to pin the exact versions of The cookbooks you're using the roles you're using Lock everything down so you can recreate previous implementations From the chef repo. So if you need to keep deploying grizzly, it's easy to do And you can say you know float on the the seven release, but do not upgrade to eight so Yes, no, we do 12 of work. Yes, but we do all of our deployments on 12 of work as it's the LTS release Tracking the Mbuntu in-betweens is very difficult You can do it. We'll take the patches. Yeah But yeah the the in-between releases are a little more Variable, but you know with more resources. We'll be happy to support those as well And so development will continue on grizzly as people you know are continuing to use it in production But as we move to Havana as we move to as we start tracking trunk with ice house You know git can easily support multiple branches all the chef tooling can support multiple branches and The review open stack org can handle multiple branches So you know I expect us to have a you know stable stable minus one and trunk pattern Going for quite a while So what's on the very short-term roadmap is red hat 6 support You know rack space is is deploying red hat 6 IBM and Dell are as well There is already some support in the grizzly cookbooks. I expect this to land in the Havana one really You know if somebody wants to continue working on grizzly they can But mostly that is going to be a bunch who IBM of course very fond of DB2 so they will be Bringing in DB2 support at ops code. We will be switching to postgres As well as a couple other folks are interested in using postgres as their database as well On the compute side, there is bare metal support already for grizzly It just has not been merged in but HubSpot is using bare metal with grizzly and their fork of these cookbooks There is a fork with docker support for grizzly That will probably not come into the grizzly branch But you know it will probably definitely be in the Havana one as docker was included in the Havana release you know if ESX Hyper-V and Zen there are definitely people in the existing community who want those those hypervisors and These are these are the ones that are not currently there that we're going to be adding so KVM Alexi we already got You know these are things that will merge into you know what we have in our big matrix of what is there? IBM wants to use Cupid for their messaging platform I had rabid it I had zero MQ listed The people who were going to be using zero MQ have stepped back in our gonna stick with rabbit if you want to do zero We're happy to take it. It's just kind of these are things. I know people are working on or already have On the networking side, there is a nicer a cookbook That was for Folsom somebody wants to take that forward port it or somebody wants to do NSX You know you could do that or any other any other neutron driver and A couple folks have expressed interest in working on open daylight, which is supposed to have its first release in December so that will show up in the Havana maybe ice house. I'm not sure when that shows up on the block storage side. There are cookbooks for Seth You know ink tank has them dream host has them Rackspace has them You know, I know that ops code is planned on using stuff for blocking object storage So that will become part of you know the different architectures that are documented at least by me and so Seth will be an alternative for blocking object storage as well as continuing to use Swift AT&T using that app through and through so Some of that should merge into the mainline stuff if you have a different block storage back in IBM has several It will support those as well So we're happy to take patches because those are very very very modular. They don't break So and then the last one there source builds via Omnibus Omnibus is a packaging tool That ops code has open source that we use for building the chef client the chef client is a Ruby application It runs on You know red hat it runs on Ubuntu it runs on Debian it runs on fedora and rel to it runs on free BSD net BSD it runs on AI x Solaris windows XP and later the re and we use the same packaging tool for all these platforms That's Omnibus. It allows you to install an application into opt with all the dependencies that it needs without depending on your distro to provide you with Ruby or You know open SSL libraries that are up-to-date or whatever So Omnibus is being used by a lot of folks for building applications that The underlying operating system doesn't have the right dependencies for you But you want to control the fate of your application. You want to manage your stack without interfering with anybody else So the chef client has its own Ruby doesn't affect anybody else installs adopt chef Put in your path, and you're good to go this ops code server does that as well. It's not a Ruby application It's an early Java application But we build that with Omnibus. There are already people working with Omnibus and OpenStack to build You know one off, you know Or not one off but to build their OpenStack packages Using Omnibus because they need back ported patches and the distros are not providing the packages that they need so Omnibus will become Supported it will not be the default obviously, but there will definitely be people using Omnibus OpenStack packages Because maybe you need to run OpenStack on something that does not have the latest Python or whatever So Zinn is the platform that our public cloud uses our private cloud has been based off of KVM And so that's one of the reasons we're going to bring in on Zinn Is there another question or? Okay So yeah, that's the Stackforge roadmap Next week the ops code community summit, so If you're having so much fun in Hong Kong, you don't want to go home. You can go to Seattle Where there'll be a lot of other OpenStack chef people who did not make this trip But there will be a lot of more OpenStack discussions there Got kind of a different cross-pollination group And so they open stack roadmap will change a little more as more people there are involved so Chef can definitely stand up your open stack it can stand up all the infrastructure for running OpenStack But maybe you're using chef with you want to run applications on top of OpenStack So knife is the command line tool that chef provides for interacting with API's You know knife talks to the chef server API knife could talk to the open stack API The knife commands that are available You know a quick list there you can list the flavors the groups the images the server you can create and delete servers from the command line And obviously list them just a quick run through of the examples, you know, hey I want to list the flavors that are available on my server I want to list the security groups that are available. I want to list the images that are available The servers that are running on my machine The reason this is important is you can create servers from the command line without interacting with the UI you can automate this You can put it on Jenkins. You can put it in the back end of other tools to deploy OpenStack nodes programmatically You know, and that's what it looks like when you SSH into a box What's good about knife open stack use the open stack API It's been, you know working since Diablo works on everything. It's been tested with all these different private and public cloud implementations You know knife open stack if you're running chef managed our infrastructure on top of open stack You know it has help that's docs Don't get up has tickets You know, I'm just kind of running through this quickly So you can see what's going on there the roadmap for knife open stack We're building a CI for it. That's testing against lots of different open stack deployments. So we can make sure that it's well supported You know, if you're using it today, you probably get excited about some of these milestones that are coming Yeah But that's that so let's talk about the walkthrough. Like I said, we're not really You know, please go and download the the instructions and You know go back to your room tonight Recreate what we're gonna walk through You can do it now if you want, but you know rather see your eyes the plan is we'll go through the setup We'll talk about the tools that are in place. We'll look at the vagrant file. We'll see what's there We'll talk about the the vagrant environment that we're using walk through the roles Look at the cookbooks actually look at some source code Log into the chef into the the open stack dashboard and talk about using knife open stack with vagrant, which is kind of cool So the setup I posted this earlier Bitly HK chef That's the instructions for how to set up the vagrant demo Once you have vagrant and virtual box installed there's a on the rack space mirror There's a tar ball of all this. It's also on github. It's the open stack chef repo Dash HK, which I think is in the instructions. Yeah, so and then you'll download a provisional a provision lure is Ubuntu 12 before box. It's just a vanilla just enough operating system Ubuntu box nothing on it nothing up my sleeve the tools that we're using Bento is a a tool That ops code uses to make just enough operating system images, you know, just very very vanilla Osses, you know, we don't we don't push chef on them. So a lot of people use them with other tools bento wraps packer Which is a tool for building? VMs, you know building base boxes that you use for the tools Packer Ios the URL then to just wraps that yes How go fix that? All right Which one's that Ruby why we're not doing a lot of them All right, is the I'll fix the vagrant plug-in order changed So the Berkshelf one has to be lost I'll check. All right. We'll get that fixed so chef zero is Is a relatively new tool chef zero is an in-memory chef server that Allows you to do things like search and upload all your cookbooks to a server and you get all the benefits of having a chef server with the big minus of no off and No persistence But it's great for testing So this allows us to actually spin up machines Without having them talk to Anything external we were trying to put this together where everything would be on a single bento box Ran into a few issues which is you know Happens so we were worried about bandwidth chef zero keeps it all on the on the box And then Berkshelf is a tool in the chef community that you use for tracking versions of cookbooks It understands get it understand or it understands github URLs local path The chef community site and so it allows you to pin the exact versions of the cookbooks you're using So you can always have you know re-reproducible builds and that's one of the really nice things about Berkshelf so The vagrant file I'm gonna pull this actually pull this file up things that will point out to the use of vagrant Berkshelf Vagrant chef zero and vagrant omnibus plugins And that we're using the chef client provider With the environment of vagrant and a run list of apt and all on one compute So let's actually pull up the vagrant file That is in the repo and the top of it. You can't see so as vagrant require a plug-in Vagrant Berkshelf vagrant chef zero vagrant omnibus. I just mentioned those Vagrant Berkshelf Reads that there's a file called the Berks file It tells you exactly which versions the cookbooks to use you can pin them you can float them you can use semantic versioning on them So you can you know really control the exact Versions that you're using a vagrant chef zero When the vagrant image spins up spins up the chef zero server and you have a chef's server available to your vagrant box Vagrant omnibus installs the chef client on the box the omnibus client this way we we can use you know vanilla Base boxes without having a chef client baked into them So if the chef client gets upgraded or if you don't want to use chef you have that option If you're familiar with vagrant, this is a pretty straightforward vagrant file you know Berkshelf is enabled Chef zero is enabled the chef zero repo path This says hey look in the current directory, and there's an environments directory. There's a roles directory And then it'll get the cookbooks from Berkshelf, and that's all I need to know It just looks in the local path. You can have a look somewhere else if you need it It's pretty straightforward On the omnibus chef version you can specify a specific version if you needed to test 1162 or something like that. We're just floating on latest, you know, we're trying to stay current Pretty pretty simple stuff then we have a little bit of configuration here for for Weird For a virtual box. We're forwarding ports from this machine We're moving 443 SSL onto 8443 so we can actually connect to the dashboard from our web browser We're opening up the chef zero port so I can actually talk to the chef server that's running in my vagrant instance if I needed to update the cookbooks or You know query information it has about the machine that's connected to it. That's kind of interesting And then the apis for open stack for the ec2 and open stack apis are exposed as well So if I had other tools that needed to test against the open stack api like knife open stack Those are actually exposed on the vagrant image That's pretty pretty slick We've got some virtual networks assigned to our VM this way we can you know create Networks for our compute guests Because we're doing all this stuff on a box We're bumping up the number of CPUs the amount of memory and we're adding the additional mix there If you use virtual box and vagrant, you know It's fairly straightforward. I say that Then we're going to use the chef client provisioner. This is actually going to run the chef client The environment that we're using is vagrant And the run list that we're using is the app recipe and then the all-in-one compute roll The app recipe doesn't have to get update that way. We have the latest repos And then the all-in-one compute we're going to actually dive into that And then we run our Ubuntu 12.04 image the host name Ubuntu 12.04 The name of the VM box ops code Ubuntu 12.04 URL there is where we keep all of our bento boxes Notice it's 12.04 provisionalists Very vanilla image that URL is pretty stable. That's our vagrant file It's actually not that complex compared to some You know compared to others it's more so let's take a look at the vagrant environment So this is our our our vagrant environment This is just a Ruby file That is injecting attributes into our environment. So any machine that runs in the vagrant environment Gets these attributes. We have a few settings here for my sequel. We are allowing remote route and Root network ACL and then we have our open stack our open stack attributes And this is if you're unfamiliar with Ruby, this is how Ruby does hashes A little hash rocket there. We are in developer mode This means that there are the passwords are things like password or you know secret. They're not There is more complex Alternatives to how you configure this We're just using the developer mode We're our identity attributes. We're using the template at back end our image attributes We're not uploading images on the fly You could set this to true and it would go and upload the glance images When the node runs and then each time it would check to see if these are there You could have a list of different images to upload with your URLs This case we're just doing seros Which is the the one from the docs for you know example deployments And then there are multiple ways to wire these different cookbooks together We're using roles. So when I need When a box needs to find another box it looks for that For a machine that has that role These are all in the same box. So the searches will say I'm looking for somebody with all in one compute Oh, it's me. I don't have to search But if I had say a hundred machines, I would ask the chef server. Hey, I need to talk to The my sequel machine or I need to talk to the the keystone server It would use the roles that map to the those services instead. So This this deployment the roles are all on one compute because you know, it's a single box deployment But if you had a larger configuration, you would just change out the roles and it would search for those instead So a lot of these roles were hierarchical where they will say, you know, we have a It could we're gonna see examples in a second, but I have you know an image role Well, the image role has you know the API service and the registry service underneath it as additional roles So that service could actually be federated federated out multiple machines if necessary and then whoever's looking for the clients API can look for the The role providing that maybe it's been rolled up onto one box. Maybe it's spread out over a thousand. It doesn't really matter This is how we wire these together But you can use alternate deployments So you see our block storage we're looking for keystone on the all-in-one compute our dashboard like for keystone all-in-one compute You know, these guys are looking for keystone to register their services The network service is looking for the rabbit server. It's on the all-in-one compute Everything's on the all-in-one compute. It's kind of convenient that way Here we have our network settings under compute We have a fixed We're building a network at 192.168.124 The public interface for that is ETH2. If you're calling the vagrant file We created an additional mix on our on our virtual box. That's what that's for for a virtualization for our vert type QMU Because you can run QMU on top of virtual box on top of OSX For our networks, there's configuration of our network our bridge You know the DNS that's how we set up our virtual box Are our vagrant image fairly simple But that's that's what that looks like So that was our vagrant file we talked about the run list any questions You know feel free to ask questions as I'm going We looked at the environment This is the the vagrant setup for an all-in-one You know I mentioned that a developer mode is true Services all have attributes and our network setup was there. It's still broken So we saw that the role that this machine is deploying is the all-in-one compute If we pull up the all-in-one compute role, which I'll do right here in the roles directory there is an all-in-one compute and it has a run list of two of two additional roles the OS compute single controller and the OS compute worker That is the n plus one pattern right there. We just put it all on one box the you know The n plus one is a single controller. So our open stack compute single controller role Could could be on another box in this case. It's the same box and then whoever's running the The compute service service as a worker, you know your hypervisor They would run the OS compute worker if we weren't doing all-in-one. We could move those to different boxes And all the compute nodes would just run the OS compute worker. Yes, so It's for chef so We're using vagrant, but this would you know, I run this on real hardware, too Yeah, this is just the example So you can run all this so we could drill down into the OS compute Compute single controller. So a single controller obviously has a lot of stuff going on We have an open stack base role We could dive into that see what that has we have an OS ops database Which is going to go and look and see what attribute you set for your database Looks like they broke the depths Yeah, okay, so we broke the The demo might be broken yeah My demo works We have the ops database calls into my sequel to figures my sequel the Open stack ops database goes through and finds all the databases that you're going to create and put some on The the the database that's there and it's my sequel calls the right command If it's Postgres calls the right commands creates the databases for You know your image service your keystone service your network service everything that has a database it runs That can be separated out, too If you wanted to run multiple my sequel databases or you know multiple sequelites or so did you call that out that it doesn't? explicitly Know so the cookbooks don't explicitly know about the database back in right you're setting it up by attributes so that you can do Whatever kind of deployment you want on the outside Instead of it being opinionated and forcing it on you You just tell the two how to talk to each other instead of them depending on or forcing each other Yes run less within run less within run within run yeah, so we had all in one single single controller which calls you know OS base Which you know goes and configures calls common which sets up the apt repos Configures the logging you know and then that bumps up to you know the OS ops database Which calls base which calls this database server? Chef it's smart enough to just deduplicate any duplicates So all the services call OS base because they all use that you know They all need to have those those same settings so that OS base is in every single role And it's a role so you know levels of inception here but you know This is our our ops database role. It calls OpenStack ops database server. It doesn't call my sequel It looks at an attribute says oh my sequel I'll go off and call them my sequel cookbooks set those up accordingly You know it does a little bit of cleanup and tuning for for my sequel And sets that up as an empty my sequel database And then we saw that other recipe comes through and creates the databases for OpenStack You know so OS ops messaging you know these It calls OS base it calls the messaging server which calls rabbit in queue configures rabbit in queue and Depending on which version of that you want And so this goes into you know we configure our database our messaging and then we configure keystone You know so OS identity You know calls OS base, and then it sets up your identity server and does registration so it registers in service Where should we start diving into The image cookbooks probably very good cooks look to start with all right So the next thing in the in the single controller after we set up keystone We're gonna set up glance so that's our OS our OpenStack image role Actually though it's important on the identity while you're doing that so we saw the image or the identity registration for the services It does all of that through attribute inheritance, so it does not do a bunch of searches There's a couple in there, but it's not Looking at your chef server looking for your environment Intuiting what needs to be set up and configuring all of the endpoints You've got the ability to set it up through attributes It'll do a basic default to 127.0.0.1. It assumes that the keystone server is itself the endpoint It assumes an all-in-one mentality But that way you can actually lay out through your environment overrides Any kind of environment that you want to just deploy so The people that have been running this in production have run into a lot of scenarios whenever you try to do Something a little more clever and to it what your keystone endpoints should be we've run into numerous Artifacts that don't work right where oh this person wants to have their public be some external BIP on an external load balancer or They're a NAT and the IP they want is actually the public IP that's on the top side of a firewall And so the chef server and chef searches has no capability of intuiting that from inside the firewall So you've got the ability to override it at the environment level to Actually lay down the exact same thing that you want to really lay down right so yeah So if you don't you know if chef doesn't understand your network topology, it doesn't have to say Here's my VIP And there's a lot of places where chef cannot know your network topology and yeah And you know in so Keystone gets set up and then we look at our OS image and Glance Does identity registration? So Image recipes identity registration, so this is a chef recipe Yeah, so We've let the different cookbooks register their own endpoints so whenever Matt was talking earlier about the cookbook wrapper model and You can put a wrapper on top of this and then play with your run list to have all of your business logic Sit inside of the wrapper and then the cookbook for the component, which is what I'll refer to it now So the glance component would through at the attribute inheritance be able to through that wrapper could do a whole bunch of business logic if you wanted to write all of that cookbook code to You know go around inside your network and auto-assemble all of these things or maybe it's querying some sort of asset management system for IP addresses of different endpoints and Then it can override the cookbook attributes and be able to register its own endpoints But as you can see at the very top of this file, there's not a search for any of this stuff It just goes through and starts doing its API endpoint to s so it's going to set up that string and it's pulling that out of the attribute So it looks a little weird whenever you first start looking at this how much information you have to have in your environment Because we don't have a bunch of the wrapper cookbook stuff there to show you how to do it So we're not making the opinionated decisions We're not doing any that business logic because really whenever you're doing this That's the code that's going to be specific to you You're going to have your own business Processes that you're going to want to have on top of this and wrapping this And then pushing all that stuff into the attributes The second good part of that is that testing works really well this way because you can test any type of scenario as long as you Can set a variable inside of an attribute that can be inherited You can come back and write a test for it on the backside to make sure that it works with any kind of deployment mechanism This is actually Identity register. This is a resource a lightweight resource in the identity cookbook In the keystone cookbook. We've created helpers that make the keystone calls So in other cookbooks, they just call the identity register and say hey, here's the image service And then yes, yes, so if we were to look in the Identity we could go down into the the guts providers and you know, there's all the You know all the all the nastiness Unpleasantness of talking to you know the key keystone API programmatically we hide this away from you So you don't have to see that if you're just writing another open stack service And so the the other cookbooks become a lot simpler if you don't have to know all this stuff The wiring becomes automatic So you have nice this pattern of hey, I need to just register my service tenant and you know it's You know you just pass in a couple of attributes and the you know the nasty wiring happens in the background You don't have to see it. You just make these keystone calls And so all the different All the different services that are using keystone, which is all have this pattern of you know the tenant the Reg the service user You know grant the Service user so it they just all do this And almost every single component cookbook has that exact same identity registration Yeah, we're pushing out service creates a service user grants it service user a certain role So as I mentioned before you could run the glance services on multiple machines So here we have the you know the OS image role Inside of it it has the image registry role and the image API role. So if we look at the OS image registry There it has the OS base yet again But it calls the open stack image registry Recipe you know and so this is You know this is gonna go and configure our logging and then platform options We've abstracted out the or encapsulated the platform information into the attributes file. So there's this Show it up So here we see our Platform options there That is going to the node the machine. That's running it saying hey pull up the open stack image platform information and If we go and look at the attributes File for the image cookbook There's all this information That platform specific settings So, you know the names of the packages these change from operating system to operating system the dependencies the dependencies You know the names of the services, you know if it's you know fedora redhead or centos, you know do You know the name of the user is glance But if we're on Susa, it's open stack glance, you know, we Have been encapsulated all that so back in the recipe It just says go pull those variables out and pass them into services into the various resources And so there's you know Susa. There's red hat. There's a boon to You know and if you have any little variations between them, you can say hey if it's a boon to 1304 It's now called this instead of what it used to be What's the relationship between recipe and cookbook so in chef a cookbook is a Package that provides the configuration of a particular application or a service so an open stack We've mapped those to the different open stack services So we have an a glance cookbook and you know the image cookbook and then the recipes are how you configure Different settings in that so for or for glance there's a registry service and an API service So those have separate recipes If we were talking about something like Apache I think Apache has about 55 recipes because Apache has mod see You know mod SSL mod whizgy mod PHP mod mod mod mod each one of those has different recipes And then you would have like the Apache default recipe that's gonna install Apache and then depending on which modules You want on top of that you could add additional recipes and it just builds that behavior They call the recipes so the the roles you know the roles can contain run lists and you know But eventually at the end of the the end of this inheritance chat is recipes You know so recipes and recipes are contained in cookbooks And we will pull up the chef client right and we can actually see that in a second Yeah, good question So 40 or 10 30 I forgot 10 30 so we got 30 minutes 30 minutes So that's the the attributes for clients, you know pulling out that platform specific information Then we install you know this is a chef recipe we have a resource called package It's gonna install Python Keystone. I guess that's called the same thing everywhere. Yeah, that'd be fixed that needs to be fixed We could definitely somebody eventually that will be you know called something different on a different platform We'll pull it out. We usually don't hard-code things But here we see our database user the open stack image DB username, you know, it just finds whatever that attribute is Finds our database password that is a helper method their DB password The common cookbook has a bunch of helpers to find to hide away to you know that sort of complexity Yeah, well that one specifically does a So the DB password is kind of interesting we do randomize passwords unless you're setting built from a mode to true Which you're doing inside of the demo But the DB password helper will actually go through and find if the attribute exists in the environment if it doesn't it auto generates a new Random password and it uploads that back so that all additional calls to that will use that new newly generated password Let me go down to the sequel connection. This is using another one of the helper So the DB your eye goes through the environment Overrides and assembles the connection string that you're going to drop inside the confile So it's going to look for things like your DB type which could be postgres my sequel sequel light It's going to set that up into the string that is expected to be inside of the confile You know so it's going to be usually with like my sequel colon colon whack whack And then it's going to start doing DB username and password so Glance at glance and then it will also set up the Connection string VIP to the database if you're running my sequel as an example if it's sequel light it's just going to give a file path Do we install curl? I don't know. Oh the glance. Oh, this is image image upload. Yeah image upload uses curl Yeah, there's so in the vagrant environment remember it said Developer mode is true developer mode is false. We have an encrypted data bag Which is a way of storing encrypted data on the chef server? It would use that That needs better documentation. Yeah, so in that case if you've got a set instead of letting the chef cookbooks Create an automatic password like the example I just gave if you know which ones you want to carry around for your ops team You can upload them and then the encrypted data bag and then whenever these recipes run It will lay down the passwords that they expect so then we have our our database type And then we're going to install our DB type type on packages So in this case I see my sequel type on packages Which you go back to that attribute where we define what they're called on Susa on Ubuntu on red hat installs them just loops over them the names of the image packages this you know again changing between platforms then we're going to create a The caching directory Set it to the right user and password with the right user and password right mode Then we're going to create the image registry Going finding what it's called on your particular platform this is actually better than it could be I mean it's then you know if we had all this conditional logic Within the recipe it'd be Much more confusing you take the five lines and multiply it by what ten every platform Yeah, so you end up with about 50 lines of code inside the inside the cookbook Here we see You know occasionally when we have operational issues that you know the field has found we fix them in the cookbooks So you know pass the value on to you Here we clean up SQLite because we're actually using a full database Then we create our Etsy glance directory and the thing about chef is These resources are idempotent that means every time they run it's safe to run the multiple times So chef is gonna go and say hey I'm gonna create Etsy glance and it's gonna be owned by this user with this group and this mode and If that directory is already there it doesn't do anything But if you know the first time it runs it sets that up Maybe somebody came in changed the settings on it chef runs again. It's like that's not how it's supposed to be Let me fix that for you We call this convergence, you know setting up a machine and keeping it in the enforcing the policy that you want on these machines This is looking to see if we have defined an interface to listen to You know we'll go and get the right address depending on which Nick you're exposing Maybe you're only listening on an admin network for connections to glance Then here we're going to we have a templated glance registry file that we have an ARB file, so ear be is the templating language of choice for Ruby So if we were to pull up that template registry Comp ERB, you know, it's your glance config file For the registry with a bunch of variables that get past into it this way we can dynamically create configuration files and OpenStack has a lot of configuration files and here you can see it's passing the various variables that the config file needs to know about Yeah, and we're really trying on this so if you've ever Done much inside a template with chef before you can go one of three ways You can define everything you want pass it into the Template and then whenever we he was looking at the template You saw things that had an at symbol and we're the variable versus node, you know, and then what looks like a hash tree So the at symbol ones are using the variables that are defined inside of the template block whenever you're passing in So a lot of people will start out by passing everything in that they want to template out So they'll collect everything that could possibly go on that file and you end up with this variable list That looks like this big and you throw that into the template and everything has got this at foo do something with it and print it Second way is you can actually hit all of the node attributes directly. So like node app would stack image service tenant name That's an attribute that set. I don't have to do anything with it to compose that And so you can not pass that into the template and the template has direct access to the node variables The node attribute variables what we've been trying to do is work towards is Little as possible, but anything that you have to compose. So inside of the recipe if you need to You know concatenate like three or four variables together to produce like a URI string That would be the only thing that we would try and pass into the templates and then use the node Attributes as much as possible inside of the templates Which is back to that whole point of everything can be overwriteable through that environment and node attribute templates Yeah And then we notice here at the end of our template if we make any changes to our grants registry comp We're going to restart the image registry service. So, you know, maybe a URL changed maybe your database connections changed you can actually go and And You know any little change that happens to that config file chef says oh it changed. Let me restart the service So it picks up that change And so and actually There's two ways do this do so This is one of the thumb parts about this being community You'll see everyone's got their own little habits. And so if you look at a get blame and see Someone from me or my team you'll see maybe this type of model where the template will notify the service The service can also subscribe to the template. Yeah, so you can do the exact same thing just backwards So the service will automatically restart itself anytime it notices a change on the comp file Or if the comp file changes you can start it and send a notification service over to the right actual service and restart it And and and with no with open stack Especially Nova there are a lot of services that share single config files like everything Yeah, everything in Nova everything in Nova No, there's not a problem with doing both now, we just haven't enforced a style It's Yeah, so I think the Nova cookbook actually does a lot of the services subscribe to changes on the template Because it was just a too many to one to do it the other way that way every little service Is just got one line instead of a template having 25 notify lines But there's also some Racy stuff that can happen on the immediately versus delay So chef can actually queue up all of those and not execute them immediately immediately means that it's going to do a template And then everything that subscribes to it is going to restart if you Do that like inside of Nova whenever you may be having two or three services on the same box That might be changing comp files inside of the same configuration file You might restart services four times during a run So that you can use a delayed which will allow them all to make the modifications But not doing any restarts and then at the end of the run it'll collect all those delayed notifications and then run them once So there's a bit of that that's So-so that's one of those operational things that people contribute a lot of fixes to yeah Because they're like I've seen this and we restart keystone twelve times in a run And so they'll go through and put a patch in to flip the way it works to get it down to a one and use delayed In this example, we're restarting the image service Because we're usually following this up with image uploading and if the registry is not Ready or it hasn't caught those changes our image uploads will fail. So, you know Live and learn so we lay down the comp file We notify the registry service, which is dependent on the comp file We start the registry service and then we go through and set up the database. Yeah We go set up our database You know more the glance registry paste I and I file which actually this is a great example if you go back up We're going to restart this service twice back-to-back. Yes And not really do much in the middle But yeah, yeah, we are not doing much in the middle But it actually if if only one of these comp files changed we'd want so yeah There there's some time a little bit of churn during a chef client run So that was the image registry the image API You know it's not that different. I mean it's just another service getting set up. It has the OS base there the OpenStack image API recipe API recipe You know this probably looks a little similar We're going to you know handle our logging Pull in our platform options install the same packages that we installed in the other one Maybe these services aren't on the same box. There's a little bit of redundancy. It's safe with chef It doesn't really matter. It says got it. Don't need to do anything got it. Don't need to do anything Here we look over our platform options. We're installing the image packages. This was in the other recipe. It's okay We could clean this up a little It's not that bad Here we have the image API service You know creating the Etsy glance directory There's a lot of redundancy in here. Yeah We could definitely clean this up You know the the policy Json as another template restarting the API service immediately Well some of that's open stack nest to like yeah open stack does a really kind of crazy job with keystone and glance specifically Where two services were expected to be running on the same box that can be running on different boxes And they both depend on the same sets of files instead of having their own directories Yeah, there's a little weirdness there Yeah, so here we're building your eyes note by the developer, you know, hey, we need to move this stuff out of here Off your I should contain to in most cases, but if it's three we leave it off You know as you start to deploy the stuff people find these bugs the nice thing is you know if you're a small shop like me You know you have people like AT&T to find these bugs for you or rack space to fix things for you Which is another reason to use community cookbooks Here we're finding the endpoints for our service Note here we're looking for the Registry endpoint endpoint is a helper method. It looks for the image registry that goes and says oh Is there you know, where's that? It's on the It's on the same box in this case, so we don't actually have to search You know building up our if we're using Swift building up our Swift URLs If our glance flavor keystone we have all this caching management Then going to see in which endpoint we're listening on You know writing the API comp passing in a bunch of settings Restarting the service template template, you know, we're restarting that service multiple times In case any of them changed independent of the others And this one doesn't have it immediately So and then we have a crime job to go and clean up the glance catch for Oh God, there's more There's a lot here and then we get into image up. Yeah, and then wanted to get to this part We have a helper built in called open stack image image This says the open stack image is the name of the cookbook and then image is the name of the service or of the resource that is is contained in here this abstracts away the Joy of of uploading images into glance and it understands the difference between Q cow and AMIs and Has helpers that you know behind the scenes will open up your Q cow files or open up your AMIs and Pass the right commands to the glance command line tool But you know, we don't want all this logic back in our recipe Multiple times, so we you know put it into a handy resource like this so So let's actually take a look at the chef client run that's happened here So we had we had our our you know our controller Roll that dives into all the different open stack services. It goes and configures everything And then it keeps coming back up Eventually goes into the OS compute worker when it finishes setting up all the the open stack services So let's take a look at what that actually looks like when it runs. So this is not live obviously but this is the output of Doing the vagrant up on the demo So if you follow along if you download the instructions and you run this on your own This is what it looks like. I just want to point out some of the things that are happening here We're going to vagrant up the Ubuntu 12.04 image So we're going to import that base box This is just you know setting it up on virtual box And then the the vagrant chef zero plug-in is going to start up here We see a chef server actually starts is a ruby application and it starts listening on port 4000 and Says hey, I'm going to upload everything that's in this chef repo. I'm going to look in the environments directory I'm going to pull the example environment the testing environment the vagrant environment And I'm going to go through all the roles that are there and there are a lot of roles Some might say there are too many roles There might be too much open stack. Yeah and then Says hey, I got all the roles. I got all the environments This is next the the Berkshelf plug-in. It's going to say hey, I'm going to upload all the cookbooks to the chef server That are in use here And so these are all the dependencies that open stack needs to run So the Apache cookbook the app cookbook the AWS cookbook, which is a dependency of my sequel so you can run my sequel in AWS it doesn't get used but it gets uploaded You know build essential for building some source the database cookbook the Erlang cookbook Used by rabbit memcash my sequel open SSL Packages isn't used anymore Postgres rabbit XFS yum, and then it goes in The works file actually has the tags and get off of github of the shaws that we're building from so it it says Hey, I'm going to go get the block storage that was known to work I'm going to grab the open stack common off this shot So it actually understands those sorts of things so as you're continuing to develop you can go in and change the Shaw as you can point it to local paths, you know pull up the Berks file You know you haven't seen Berks file You know you just list the cookbooks from the community site with the versions or you can list Here we were just pulling from tip You know off of well we ship the Berks file locks. Yeah, actually we ship the lock ball, but You could delete the lock ball and then run off a tip So you can see all the shots are there on stack for community cookbooks Right and the nice thing about using this type of thing is that development can happen on the different component cookbooks But that doesn't mean you have to immediately start consuming it so Whenever we have something that we get past our tests that's enough that needs to be pulled in to the cookbooks We can go and change the Berks file lock to point to the next version So let's say we start at 7.0 3 or 4 developers do different bug fixes and we get to like a 7.0 4 If that one is one of the ones that has enough Fixes that we want to bring in then we can go back into the cookbook the ops code Chef repo and actually update it to use 7.0 4 But the whole time it's still been on 7.0. So there's been development going on But if you were doing deployment you're stuck to stable. Yeah cookbook So we're trying to keep stable stuff in the chef repo You know so it's stable To be done there. Yeah, so here we see the chef client or the vagrant is Uploading all those cookbooks pulling them from get with the the Berkshelf plug-in and Then it uploads them all to Chef zero, which is running on the box Then it does the standard vagrant virtual box set up of you know creating our shared folders the here We're forwarding our ports 443 for the forward 4,000 for Chef zero so we can actually use knife from our workstation to talk to the vagrant image Yeah, and the EC2 and open stack API's Not yet not yet. This is all setting up the VM, you know and then You know we see waiting for our machine to boot Machine booted and ready. So it's the host name configures our Stuff and here is the omnibus says installing chef 11 8 omnibus package It actually goes and you know in the vagrant far. We said latest it checks with Omni truck, which is the API service at ops code says hey, I need the latest version downloads it installs it You know here we see it installing chef. Thank you for installing chef and then it Registers that machine with chef zero. It says. Oh, what's the chef server that I'm supposed to use chef zero It's on the same box nice and fast doesn't have to go out to the internet and Then it starts our chef client run That's the part I want to talk about right there the run list to the expanded run. Yeah Yeah, so here's our chef zero run and then here we see our run list of Apped and all in one compute that we passed in from vagrant says hey, this is what it was set and then that gets that gets expanded our Run list expands to that that is open stack all-in-one all the recipes There's a lot of them And open stack keeps getting bigger And the last thing we see there is open stack compute compute, which is our compute worker role So it actually goes through sets up, you know the database the messaging Image our identity image network on and on and on And so here we see you know starting that run with that run list And downloading downloading all those cookbooks, which are local. So it's nice and fast Keep going Then it starts doing the chef client run creating my sequel You know creating our database users for different services dashboard keystone glance salameter quantum We have salameter running, but it's not actually used right, but you know it will be used for Havana Then we see you know the rabbit in queue configuration Keeps going here. We see keystone creating bootstrap admin users Okay, compared to that right space doesn't use that stack. That's an open stack project. Yes I mean to some degree they're both a little bit comparable because they're both attempting to do the same thing by Managing the comp files and laying down open stack Dev stack was meant to be a really simple way for people to look at how you're supposed to configure it and to do some testing It allows you to use different get branches for all the different projects and run testing harnesses against it And it's used for the gating and upstream This is more targeted at production deployments, so you know you can lay out your environment to define your Deployment and then be able to run through it and get exactly that deployment and guarantee consistency with chef client running every 30 minutes And whacking every single file change that you make by hand right back to what chef wants it to be Yeah, that stack is not for production. Yeah So, you know the chef client run goes it does glance it does quantum You know it does Set it up your networking L3 agent. You're networking. I'm going through this fast because we're getting towards the end of the session Sender and the volume setting a bar I scuzzy, you know each one of these is going back to keystone Here we are setting up the dashboard and then Installing packages Then our compute nodes the compute service starts up lib, you know, Libber been whoo, and that took 200 and 2,100 seconds If you do the math, that's slow a virtual box is slow and My network was slow, but that's why I canned it so we didn't have to sit through it and then Then the VM actually came up So this is the end of the chef client run and then on the live machine. I did vagrant SSH Ubuntu 12.04 and logged into my VM Here I fixed the the ps1 Source the open RC. This is all the instructions. So source the open RC listed my Nova services. They all came up You know, they're all the Nova services that's the hypervisors the quantum agents and Then I did glance image create the seros image from the URL. That's in all the documentation and That brought in our glance image You know that can that part can be automated, you know, here's the list of the images it worked Then I did Nova boot test an image And it built that seros image Looked at it That's pretty cool Show it to me. Yep. It's active Well, let's go ahead and SSH into it. And so actually SSH into the seros image and did a PSA UX, you know, hey seros Exciting think you want to yeah, it's probably possible. Yeah, I would not recommend it The question was can you call puppet scripts from inside of chef clients and you probably could if you want to do all that work But you know, this is the VM I Think I just egged it out of it, but that was actually running top on the seros image so That VM is so I'm running a VM on top of a VM on top of OS X Inception There are people who are doing that. Yeah. Yeah, there's there's some work on that. Yeah, that's actually one of the things they're working on thrice house is pulling in more of the config management providers as first-class extensions inside of heat So then that way you can orchestrate and because right now you can do it You can pass it in different shell commands into a heat template and execute whatever you want But they're gonna actually try and bring those up as to first-order attributes and be able to integrate chef and puppet and salt and ansible those things And the heat and the dashboard is up on our Our VM So I think if we go to project Instances there's our seros image So I'm actually accessing the dashboard of the VM and looking at the VM that's on the VM And that's our time Yeah, so In the the we had a developer discussion yesterday of people working on these cookbooks There would definitely be some upgrade work being done IBM said they already had it. Yeah, we do so that There's a little bit of weirdness on that Most of the people involved are contributing upgrade stuff However, we're finding Some things that we could probably work around in chef on the open stack upgrades themselves But sometimes it may involve you running a couple of hand commands before you do chef runs on your up on your nose to upgrade And that changes between every single version We've typically found about three artifacts on all of the upgrades that You end up going okay on your keystone server go and do these two commands first and then run through and Or you know the last one maybe it was a glance one or a cinder one But yeah, that we're gonna be working on that will eventually get gating on upgrades in there, too Documentation is always in progress. Yeah, and it's all up on github and as I mentioned, you know, I'll put the slides up That's a longer question and Is it time or? Yeah, so Saved by the bill so thank you very much and You know, please take time you follow the instructions