 They helped us get it actually started. It's a collaboration project but because of their generosity I was able to take time away from installing other stuff or not open stack stuff to actually work on just this community. So they were a big motivator behind the project itself because before I was helping lots of people do open stack but nobody was talking to each other and that's kind of what we're doing here with Chef for Open Stack. The Rackspace, their Alamo project, it's going well, check it out. It's a bootable USB stick or ISO to see how Open Stack looks, peel away the covers. It's almost the same code, we're sharing a lot of that code. The Rackspace guys all got to go to a football game tonight so they're not here. But well sorry, sorry you two, the rest of your team they left. But most of the other people up here are actively engaged and working on stuff as well. So what I kind of hope to talk about is here's what we got, SX is working, KVM Ubuntu, LXC, some Calzada guys are over in the bare metal deployment talk but they've got LXC working with these cookbooks because they're running on ARM CPUs. Swift, Dell has some cookbooks, Rackspace has some cookbooks, Dreamhost does not have Swift cookbooks but I have not taken those and cleaned them up to make them more accessible from Rackspace and I'm not sure, do people want SX Swift or should we just go to Folsom? Because this is a conversation, feel free to say like, SX, Folsom, Folsom it is. So the point made by the gentleman from Dell was that Folsom was easy to use because a few small tweaks and it just worked and I was talking with Rackspace earlier about their work for Folsom and they said they took the Alamo stuff, changed a few URLs, fixed a bug and Horizon and it works. So that is, yes, we're not doing upgrades, sure, sure, sure. But the point is we won't be starting from scratch. There are definitely Swift cookbooks that exist and we will be leveraging them shortly. It's just, sorry Swift guys, Nova is a little more glamorous and so it's gotten more attention lately. But these are the things that are on the road map for the project. Documentation, I've been pulling the readmes and various little bits of documentation that are sprinkled throughout all the cookbooks and projects and everything and pulling them into OpenStack Chef docs and converting things to Sphinx and restructured text so we can make PDFs and multi-page HTML things and it's very shiny and you can make EPUBs and real documentation and at some point possibly moving some of that documentation to docsopenstack.org. I put it on the same license so it'll just move right on over and they're using restructured text but they're using Doc book or whatever. I'll talk to Ann Jennell about that. That documentation is up. I've been pushing to it furiously like the last three or four days. Hypervisors, KVM and LXC today, does somebody want something different? If you want something different and you show up with patches, we will try to make that work. I know that the SmokeStack stuff runs on top of Zen but that's the only place I've really seen somebody running Chef with Zen. If you want Zen, show up. You're going to be the supporter. The funny thing about all this code is of course it's community driven. I'm the one guy from ops code and there's like 10 guys at Dreamhost and 10 guys at Dell and 10 guys at whatever. In order of magnitude more than one. There's more than me. The way this project works is if you want a feature and you show up with the feature, it's in the project as long as it doesn't break other people's stuff. Rackspace is working on REL6 support right now. I've been asked about that several times. I've been asked about Postgres. I will introduce you to someone else in the back who's making fist pumps in the air about Postgres. So Postgres, we can just start that up in the Folsom branch and start changing the way that the roles are laid out. Instead of searching for the MySQL master role, we'll start looking for the database master. Which brings me back to some patches that I haven't merged yet from AT&T about not using roles for search. They want to go back to using attributes. I'm cool with that because it doesn't break other people's stuff. Yeah, if anybody wants to dive in, I would love to have support for that. I would love Slez support if the SUSE guys show up and they want Slez to work and it doesn't break everything else, I want it to work. I mean, there are people who are asking for every sort of permutation under the sky and it's a patchy. Let's do it. Is that a question or a fist pump? For anyone who doesn't know, next week is the Chef Developer Summit in Seattle. So that's a bar camp type thing of Chef Developers. Exactly. So, I mean, yeah, there will definitely be, we will definitely use that as a reference. We're burning, or not Betty, Betty to Fred. I thought Betty was Essex. Gender bending. Yeah, so yeah, that's people introducing people. The fist pump were in the back. Do you want to say who you work for? I mean, yeah, okay. And so yeah, there's Postgres support in the crowbar cookbooks and the smokestack cookbooks and it shouldn't be hard and we'll make corrections in the various logic to move away from specifying your database in the names of the roles instead of saying MySQL Master, we'll go to Database Master. Instead of RabbitMQ Master, I think is what it currently is, I want to move that to Messaging Master because there's been talk about bringing in either active or zero MQ. Yeah, Cupid too. I mean, we want to generalize it so we don't have to care. Yeah, I mean, I know it's there. I just, we need to clean it out of our current mode. Yeah, show up in IRC and we'll talk about it. I just mean instead of searching for the MySQL Master role, we come up with the database master role that under the covers and attribute has set it to Postgres. Yes, yes. No. So let's talk about upstreaming cookbooks. You know, there is, I was pointing out how many other people there are besides me and so a lot of the work I do is really just picking from other people's branches and merging them into the Chef for OpenStack and then other people are like, oh yeah, that's cool. And then, you know, they go off and then they come back with like six months of patches and, you know, so I'm outnumbered. But if you want to be like the owner of some feature, if you're like, you know, I don't like calling it MySQL Master, I want to be the guy who owns the database, you know, the database stuff, I would love to give that to you. And if you want to be, you know, the people who are like, hey, we want to make sure Chef works for everybody besides just DreamHost, you know, I'd love for you to do that. There are some folks who are working on getting CI set up on top of this. And hopefully, our Metal Cloud has given me, you can have as many noses as you want. I was like, cha-ching. So I will probably set up a lot of Swift stuff when I start testing with, you know, I've got four boxes in my lab. So when I start testing at volume, I'll probably be going there unless somebody else is like, hey, Matt, let me send you some hardware. And so, you know, if there are people who want to step in on things, you know, it is, it works today. Essex works, you know, we'll probably break it a little bit for Folsom, but you can always go back to Essex and it worked. And then we'll start working on supporting more complex deployments. Right now, it supports what Rackspace Alamo supports, which is all in one or in plus one. Or one plus N, where you have one controller and compute nodes, which, you know, that doesn't scale past like 20 or 30. Yeah, yeah. So if you look in the OpenStack Chef repo, I've got a file in there called todo.org. It's my Emacs org mode that just, it's the backlog of like wishlist things that it would be nice to clean up. I think it's like number two is, is make sure that every service safely runs on other boxes. And with my four boxes, it was like, I'll put my SQL over here and then we'll run the other stuff here. Okay, that worked. You know, cycle, repeat, and it's kind of slow. But yeah, so thanks. Yeah, we'll get that merged out. I expect Folsom work will probably start like, I'll start actually get back to my office in about two weeks and we'll start putting Folsom out from the main line. If you want somebody else's branch, Rackspace said it works for them, Dream host says it works for them. Dell has cookbooks that work. There are other private, or there are other repos that are not advertised, that are publicly accessible, that have Folsom working as well. I'm not gonna say their names because they're not here. So yeah, there's definitely Folsom work that's already done that you can jump on if you're in a hurry. If you're slow in plotting methodical like me, it'll be at least two weeks. But the nice thing is I'm actually writing more documentation than coding at this point, which is where I wanted to be. The repos don't have to be named the same thing, or product-cookbook. So move things like Nova to Nova Cookbook? Well, so I mean, the Nova currently is over in, GitHub, Opscode-cookbooks slash Nova. I mean, that's pretty descriptive, but when you fork it into your repos, like now I have two Novas. So yeah, you have to rename it. But you can rename it, and then when you bring it into your cookbooks directory, you can rename it again. I mean, that's how I got around it for, I'm doing it with something already myself, but do people want me to rename the repos? I don't think there are that many followers where it'll rock their world too much. Well, I mean, that's a GitHub problem. I mean, it is a problem for Joshua Temmerman, who's our community guy who does most of the cookbook management, but not this cookbook management. It's a GitHub issue, really. I'm happy to rename them. I don't think there are that many. If you're following the cookbooks, I will go rename them, and I'll find all the followers and send them an email. It says, yo, I changed the name of the repo that you were using as a remote. Well, GitHub's just adding this layer of magic on top of Git, you know what I'm saying? Yeah, so, as far as, that's the basics of Folsom. When we start diving into the new pieces, HA configuration, Florian Haas has a talk tomorrow about HA for OpenStack. I believe that is the documented way to do HA with OpenStack. It's not official, it's not required, but it's a pacemaker with Galera for my sequel, and I, you know, boo, yeah, I hear you. I do, that is finished now. Yeah, the pacemaker stuff, I started a bar clamp for Crowbar. It sets up the services, but it doesn't manage any of them. So, pacemaker gets ready, and then it's like, then I ran into the problem like, oh wait, you know, every service inside a chef is thinking it's gonna be able to restart services when pacemaker's one is gonna be managing it, and so they're gonna conflict, and then I just was like, I'm busy, you know. Well, I mean really, I got busy with something else, and so people who asked me, hey, is there a pacemaker cookbook? I'm like, it's half done. You know, a pacemaker's up and running. What more do you need? Mine enables it and sets up like the masters and slaves, and they all know about each other, but none of the services are managed. Because then it's, yeah, it is really insane, because I started thinking, well, do I need to monkey patch something, or do I need to extend the chef base service to be a know-op, and so there's an alternate HA implementation that one of the gentlemen from crowd scaling stop by, I don't see if you're here. He's got to talk, I think, Wednesday about how they do HA that would not be using pacemaker that uses like BGP routing, and he said they're thinking about open sourcing those cookbooks, so maybe we look at that. I don't know. Or we can have us, I can sit down and try to stick somebody who knows Chef a lot better than I do on pacemaker itself. Yes. Yeah, Carl wears all those hats. But yeah, I don't know what the right answer is for HA, but it is something we could start taking a stab at. So yeah, that's officially supportable with Folsom. It's a good topic for the mailing list, or the summit, yeah. All right, so now we've got two talks for the summit. We've got another general open stack one, and we have a, can we do pacemaker services? As well as Galera is not that exciting, and RabbitMQ clustering is, well no, no, it has its own clustering stuff. Yeah, yeah. Or not use Rabbit, and then something else, but it's not DRBD, so it's not HA pairs, it's an HA bigger than pairs, yeah. Quantum, so quantum, who's got quantum running? Okay, what are you running? There you go, so for the record, I'm looking at the video camera here. Carl Perry from Dreamhost. We'll make sure that we get some working quantum cookbooks out there. I believe last time I talked with RxBase about it, they were going to stick with Nova Network until they had a customer who had a real use for quantum. Sounds like we have a real use for quantum here. Somebody is using it in anger. There is, there are other implementations out there that are not NYSERA and not OVF, and we'll be working with those as well. That's how it should be. And using that same pattern, I plan on applying that to the database as well as to the hypervisor. The hypervisor currently just is like, I'm gonna do Liberty KVM, and it's all mixed in with Nova, and we're pulling that out. So you can say, here's an attribute. What are we gonna do? KVM, LXC, bare metal someday, maybe, I don't know, continue supporting Nova. I mean, I know you have the opinions, but yeah, well that's all we have support for. We're just for the mailing list. We will continue to support Nova Network at least through Grizzly, because that's as long as it's supposed to last, right? Well, I thought it was being dropped after for Grizzly. Some other session will probably answer that for us. Sender, RxBase is using NovaVarium, and you guys had a, somebody told me they had patches to remove. To make sure it did not blow up, because right now, if it's, in my setup, it just stack traces out, and I don't care, because I'm not using it, but you guys are using it, right? Well, so I'm not like, just farming out all the work, I'm actually gonna be doing professional services for a customer on Folsom Cookbooks, and we'll be open sourcing it, so maybe I'll do NovaVariums, or Sender, sorry. Not gonna own it, that's fine. Does anybody want Solometer? Yes. Yes. Okay, well, I do know that there's another Solometer cookbook, at least in the works. Do you have one? I thought I saw you say you were right in one. No, all right, never mind. I'll get back to you on that. And I expect there are other people who are interested and will be working on it, you know. Is there, are there any other projects that should be on our radar for Folsom? Is there like somebody who wants us to do an idea or something like that, or? I just saw that, I thought that was a neat project. You know, the glacier. Well, I mean, it's really, if you want heat, you know, bring it. Because I don't really, I mean, I'm not a, you know, I don't see a lot of it in my day to day, so it doesn't, I mean, I don't see a lot of cloud formation myself, and I see a lot of AWS. So I don't, it's not motivating me. But if there are people who want it, we want to support it. You know, it's, you know, just cause I don't like it, it doesn't matter. You know, it's a community effort here. And, you know, we'll have a flag that says heat, yes. So other projects are kind of building off of this ecosystem. You know, the nice thing is, you know, I'm the author of Spice Weasel. It's picked up a lot of traction because of this, because I was using it. I switched to using Librarian. If you're not familiar with Librarian, it is a tool for managing your cookbooks. Spice Weasel also manages your cookbooks, but it doesn't know anything about Git. Librarian does, and so I had to switch over to something that was Git. I will be happy to add support for WISC. So Duly noted, the gentleman in the back who's an author of a competing tool. I don't care. I mean, if you want to take the Librarian stuff and show me working with WISC, and it just works. Yeah, I mean, we're not strongly attached to Librarian. It just, it works for our use case of, yeah. Yeah, and I switched to Librarian from Spice Weasel because Spice Weasel knows about the community site, but not everything was up there yet. And so, yeah. And Librarian, I'm able to track my forks and give it branches and tags, and that's, as far as I know, all I wanted. But I did not want Git sub-modules. So if somebody says, how come you're not using Git sub-modules? It's because like, there you go. Duly noted the man from Dell for the record. I said, you know, and you guys were the ones who encouraged me to do it, but it was, I came to that realization a long time ago. We don't use Git sub-modules because they're, I mean, that's like, you know, advanced Git foo, and I'm trying to make this accessible to everyone, which is why we're using tools like Spice Weasel and Librarian and saying, you know, just run this command and all your stuff shows up in the right places. If we want to make it work with WISC or Berkshelf, I don't care. Yeah. I mean, once it's in place, it's easy to keep them in sync. It's like, I replace the one here with the two, four files. Yeah. So yeah, what Spice Weasel gives us is it also manages the roles, environments, data bags, and pushes those up too. But I've been meaning to either have Spice Weasel understand those other tools or take the patches from Spice Weasel and push them into the other tools. I don't care. Pixie Dust, if you do not have a solution for provisioning your hardware, who's written their own? Yeah, so as provisioning your hardware is like, you're going to have to do it. That's not a chef thing. You know, you can use a nice tool like Crowbar, a nice tool like Nephology, a nice tool like Cobbler, or you can write your own. Pixie Dust is a very minimalist. Pixie booting, TFTP, OS installation. It does Ubuntu 1204 or Debian 605 off a pre-seed. That's all it does. And puts chef on the box. So you will need to solve that problem. That is not in the umbrella of chef for OpenStack. You know, you need to have boxes with chef on them. And, you know, there's Crowbar, which is kind of parallel to a lot of this as well. And so these are projects that have a halo effect. You know, some of the work that they do comes back into Chef for OpenStack. Some of the work that Chef for OpenStack does goes into things like making the rabbit MQ cookbook suck less. Or, you know, the database cookbook. Yeah, I mean, all the cookbooks are getting benefits from this. And I guess I need to add a bullet point for when I give this talk tomorrow more formally. You know, Test Kitchen. Test Kitchen is something we open sourced about six or seven weeks ago. It's a test framework from Opscode. It's all open source. That will run, use it to run tests against your cookbooks. So it runs men test, chef's spec, cucumber, food critic, you know. But it runs them against vagrant. Which is, you know, it's great if you're running a Mac. But, you know, some of us aren't. I am, but there is an OpenStack provider that's like Ticket Test Kitchen Five or something like that. Okay, yeah, sorry. Vagrant does work with Linux as well. I always just see people complain about it crashing their Macs. Mitchell? Yeah. So, Mitchell Hashimoto, the guy who's, you know, behind Vagrant Up, he sponsored by VMware to make it work with Fusion. Because, you know, they don't want people just using VirtualBox. Yes, yeah, that's actually why I don't use Vagrant as I use Fusion. But the point is, Vagrant's gonna take a while to get to, you know, more back ends. And Test Kitchen is, we wanted it to run against OpenStack. So there is an OpenStack provider. So, you know, you'll be able to, the way if you're unaware of Test Kitchen, it says, you know, hey, here's the cookbook I want to test, here are all the cookbooks I want to test, here are the operating systems I want to test, you know. And so it will, you know, do Ubuntu 10.04, 11.04, 12.04, Debian, 32-bit, 64-bit, Windows, whatever. And it runs them serially, you know, VirtualBox, I mean, Vagrant, bring it up, run the test, bring it down. Bring it up, bring it down. It's a patch set. I don't think it's been released. Yeah. And so rather than use Vagrant, we could use OpenStack and we could probably do it parallel and it'd be a lot faster. Yeah. And we use, you know, OpsCode's plan for Test Kitchen is we're going to run all of the community cookbooks with Test Kitchen. And we have a big rack of OpenStack gear that we have and we're going to make it all work on that eventually. So we'll probably talk about that next week, you know, at the summit, but, you know, Test Kitchen's all open source, you can use it today. It does not have to be running Test4Chef. It's just a test running framework that currently uses Vagrant, but if we could get it to OpenStack, then it has all sorts of other useful features. So once you stand up your OpenStack Cloud, you could use it to test your company's application. So that is probably enough talking for today. Is there anything somebody wants me to talk about in addition that I might have passed over? You're like, why didn't he talk about, yes? So yeah, the CLA question. I have been asking people to fill out the CLA because this isn't, we, you know, OpsCode asked people to fill out a Apache licensed CLA to ensure that you were giving code freely. You know, we don't want to get into the Neville, you know, or was it Neville? Not Neville. Sco versus Neville versus IBM, drag it on. I mean, it's the Apache CLA. Yeah, exactly. I mean, chances are very minimal that someone will be like, oh, you took my patch and now I'm gonna sue you. But we do it, you know. So yes, this is an, this is a OpsCode sponsored project. We do try to get the CLA out of everyone who's contributed. Rackspace has done it, Dell's done it. And Dreamhost has done it. HP's done it. Sousa has done it. Yeah, I mean, we were, and then we'll talk about it at the summit some more next week about what we can do to make the CLA even better. If you have an existing OpsCode CLA, it's already covered. You know, we don't make you do it like, oh, now I'm contributing to this plugin. I gotta do it again. It's like, yeah, you do it once it's good. Apparently it's not that bad. 930 people have already done it. And 170 companies have done it. So, you know, hopefully your employers on the list will get you added. You know, it's Apache. We just covered our, you know, back sides. I'll be around. OpsCode booth is out there. I've got this, a real version of this talk tomorrow for, you know, your bosses or whatever. Tomorrow 1.50, we have a deployment panel tomorrow. Party tonight. Dreamhost, Mirantis. Thanks guys.