 Ready? Okay. So sorry about kind of the compressed timelines of this. We had obviously the last session when it was coming in, so thank you very much for attending. Oh, let me open this up here. So I've noticed there's been a very differing amount of people attending an OpenStack summit and between the user session, the user DevOps, and the design summit. So opening it right up. Who has contributed code to an open source project before? Okay. So about half the people. Who's contributed to OpenStack so far? One person. Okay. Very cool. So this may be appropriate. Those who haven't contributed to an open source project are contributed to an open source project. Who's here because they want to learn how? Perfect. Cool. So what we're going to talk about today is write up that alley. So a couple of things. I want to go over how this all started, kind of my journey in this. There's a couple of people in the audience here that have gone through the journey with me. I think Vinay, are you here? Vinay Benai. And anyone else from Silicon Valley OpenStack meetups? Okay, cool. The story of kind of how this all started, a very simple experiment, and who to blame. The importance of the community, some of the things that we've been doing. How to talk to your employer into allowing you to contribute to an open source project and specifically OpenStack. Some things that I like in my dev environments, including how my dev environments set up and then how our dev stacks are set up, I'll ask another question. Who's used Git before? Okay. Who was comfortable with it the first time? Exactly. So those who've used Git before, you are much better prepared than I was walking into this. And so if some of the stuff seems pedantic, please bear with me. For those that haven't, it's very struggling. Testing the code and then how to give back in the community. So are these topics, things that you guys want to hear about? This isn't me presenting too. This is a conversation as a community, so please feel free to interrupt. I don't claim to be an expert in anything, but no people who do. So crap, the picture is again wobbly here. So a little bit about my background. I'm an engineer, right? So I'm a network engineer first, designed some web-scale infrastructures, storage and systems engineers second, done a bit in ITF, IEEE and T11 protocols, participating more as a lurker in the working groups, been a heavy Linux user since 98. And for the code that I write is generally built around automating deployments of very large infrastructure, and specifically it's sausage code. This is something which Sean Roberts, who's on the board and runs the OpenStack Meetups in Silicon Valley talks about, that it's a whole bunch of scripts built together. For me specifically, it's about getting, if someone's going to take longer to do it manually, I write code. I'm not a programmer. This presented some serious challenges for me and the people that I went down this path with in the OpenStack Meetups of getting to our first contribution. So let's talk a little bit about how this craziness started. Who here is participating in a meetup or a user's group working with others for OpenStack? Okay, a small number of people. So I started actually about a year ago, I had some large customers in Silicon Valley that were evaluating different alternatives to Amazon web services. So they had a lot of stuff up at EC2, evaluating Eucalyptus, evaluating, OpenStack was one of them, evaluating CloudStack and I'm like, hey, what's this cool neat stuff you're talking about? But I live in Silicon Valley and for any of you who live there, it's 50 miles of stupidity. So we do just a whole bunch of crazy stuff that no one in the world wants to do. It's not very appropriate. Every once in a while stuff escapes Silicon Valley. And this spring started hearing about OpenStack from customers and my engineers all around the nation. It's Seattle and San Diego and Atlanta and Boston. And so it really got me down the road of putting stuff together and actually building these OpenStack environments both for internal use and to learn more about it. And what came out of this was this natural evolution of I was really lucky that Yahoo's in my backyard and Sean Roberts had put together some of some meetups. I went there to go to a beginner session, realize the beginner session I'd already knocked out and sat down in an advanced DevOps session actually with Vinay sitting back there and got into a simple challenge. So for those of you that don't know, so Ewan Mellor's a developer for Citrix, a really cool guy. He had a simple idea, so a simple experiment in the meetups. He said, hey, we're going to get 12 to 14 people, we're going to divide into three teams. Party, exactly, Vinay is laughing. And within a three hour session we're going to design, test, document, review and merge some code. Very simple code. Very simple. The feature that we were going to work on was a storage QoS. So this is the ability implemented through LibVersh, if anyone used Libvert, to go ahead and basically take a VM and give it levels of priority for the block IO tuning down inside the VM. Be able to extend that up into the APIs and then actually make that available in Horizon. This took four months, so not three hours, it took four months. And I don't think it took that long because we didn't know how to execute in writing the code, but there are a lot of the challenges that we face on how to work with the review process, how to work with the other teams that are working in the project, the basics of Git. So the first thing is first, and this is the first thing, the half of you which didn't raise your hand. Meetup.com, the OpenStack Meetups, the local users group, we would not be actively doing anything without leveraging peer groups. Meetup.com saved all of our, but I mean, Vinay, do you think we'd be able to actually check code in without it? No. In Meetup.com, not being the product, but the platform, but being able to get together as groups. There's a range of people we've been finding as we've continued participation in them that people from all these different areas of the industry, we all kind of, actually I should take off my badge right now, but we're all going to take the badges off, and even though some of us are working for competing companies, we're all learning together. It's very, very powerful. Okay, so for those that haven't raised your hand, there you go. Next thing that is the challenge that I face, and I'm lucky enough to be a direct level position, yes sir? Yes sir. So what would happen is that we could spend literally in a hackathon figuring things out, and maybe one to two percent of the time actually getting stuff done versus 99% waiting for an answer on how to do something, who to talk to, how to push something through, just simple, simple, stupid stuff. And again, you always have to come back to, I don't develop for a living. I functionally, if I have to deploy 1,000, 2,000 routers or servers, I write scripts to make it easy and make sure it happens, right? So not having that background is a lot of challenges, but also there's some really good developers that have joined with us that also face the challenges. Can they answer your question? Well, my hope is by sharing some of the lessons that we learned that the ratio becomes a lot larger act of development versus getting through simple stuff. Yeah, I mean for example, this morning I was updating my presentation taking screenshots, screenshots, and I pushed a change through that's in review. So, once you get past the initial, there's just a large roadblock to the beginning of it, a very large roadblock and little stupid things that trip you up. So that's the goal is to remove the stupid things. Again, I'm not lying to store vaults, right? I'm an engineer who's managed to get to a point where I can contribute in a morning while hungover to OpenStack, right? So, and this morning accepting it pushed the review process, it takes a little while. So, who actually knows their employer's open source contribution policy? Okay, who's contributed without it or in violation? Okay, I won't have anyone answer that. What's really interesting, and I know about California because that's where I live. So there's a lot of rumors or conjecture and I'm not a lawyer and don't take this as legal advice, but what I find is that and I actually went through this myself, I didn't have a defined contribution policy. And there's two ways that we can operate inside of this, that and one of my architects is staring at me, so you're okay. But first thing is you really have the legal obligation to notify your manager. Now there's two ways you can tell them this. Hey, I'm doing something you don't completely understand, or you can provide them a form letter talking about what you're doing and how you're doing it. And what I've found is that Silicon Valley is almost stupidity, but an area is outside of the nation that are outside of that bubble. That people are pretty supportive with the goals of I'm working on code to develop mastery, lower the cost of integration of this product that we're bringing in house, as well as to be able to push requests for other people in the community to help me manage my infrastructure. In California, so who's here from California? Okay, and who here hasn't signed an ICL in California? Everyone has. Okay, so who has a corporate contribution license of those? Okay, so only about 30% do that. So in California, you're only protected if your business isn't going to get in that business, or will not in the future. Yes, it is really important to get a CCL sign. I mean, for example, that's why Nexos has, my company has a CCL posted to protect our engineers, protect their intellectual property. If you are going to play that balance, do it at night, right? Don't do it on work hours, I'm just be aware. Next step, so who has an executed CLA already? Okay, Contribute License Agreement, pay close attention. So if you're going to contribute, this actually, this trip me up. So a first thing is you got to create, there's Launchpad, right? And this is an account, it's basically an open ID platform that is really, really important to your contributions. You're going to get notifications of projects that people are working on. It's really closely integrated with the review process. So you're going to create an ID here, right? Now if you're like me and you like everything to say call in McNamara, so everyone can finally find you publicly, you may go in and change your username. Don't do that. I had written code that was sitting stuck in a queue for, I think, a month. And I was only able to fix it and I'll get to the last bullet here. Next thing you do, so join the OpenStack team on Launchpad. This is documented but I find, frankly, I didn't follow the documentation. You'll sign the CLA electronically, right? So you get this thing back, there's a link, you get a piece of paper. And then what you end up with is a serial number. You got to take that, this is not the most elegant process. Update the wiki and then request OpenStack contributors CLA. I hope so. I got hung up on this, we had working code, yes sir. Okay, so and then what's your step? Isn't that open, now you have to be a member of the foundation. Okay, I'll update these slides, thank you very much. Yeah, so it is hard, right? And then here's the big one, had waiting, had code written, waiting to be checked in. And by the way, if your code's written, OpenStack moves so quickly now that you're gonna be merging your code and especially if it's an API, it's gonna be a lot, right? So you'll have to commit up and commit, with commit, commit, that you'll have to import in and it's kind of hard. A way around this, on IRC, PoundOpenStack, or PoundOpenStack, OpenStackDev and OpenStack.js meeting, don't pounce on a meeting. But OpenStack.dev, if you ping the ops, I ping Soren Hansen, right? So I think he works for Lutucker and Cisco. And they said, hey, I got code, I am waiting to commit. And ironically, I committed it at 6 AM, while I was at VMworld. But, yeah, awkward. But you can go ahead and ping the ops as, if you get your membership set up towards when a launch is happening, or if in your release canvas, what's gonna happen is the same people are actively coding, they're not gonna push it through. So you kind of have to tell them. So let's get to the same Devmar. So who has a Dev development environment right now? Okay, is it on your laptop? Is it home? Anyone? Both? Okay, who likes to develop on their laptop? Okay, so if you do that, who does it natively and not using a VM? Okay, so only a couple here. So we won't get too deep into that. So there's a couple of things that you can do. So one, we'll get into a little bit of how my Dev environment set up, which I will point out has always been up and available for our hackathons. But a couple of things, and sorry about the weird squiggly thing. So DevStack is a development tool for OpenStack. It is not a fully working version, you might say. I mean, you can create instances on it, but it's made for development. You can basically, on Ubuntu, get, get, clone it in, and then CD into DevStack and run Stack. Now, beyond that default DevStack, what I find, what I see people doing, is, you know, Vinay, for example, puts on his laptop and has a wireless IP and it loses its mind, right? I actually like to run it inside of VMware infrastructure. Sorry about bringing up VMware, but, you know, there's a lot of integration and test points. What I find really convenient inside of this, is that it's really easy to spin up another instance. So I got my puppet servers in there. I have Ubuntu 1204 templates. I can checkpoint if I'm making a change. I can run multiple DevStack instances side by side. This is from an engineer's perspective, by the way. Not from, because I know you can set up multiple horizon instances and check them, but yes sir, because this is, so at home, I didn't go into the big depth of my lab. I have 24 terabytes of Synology storage, three of the little shuttle low power PCs with 32 gigs of rams and Core i7s, and just works okay in a distributed fashion. You could use whatever tools you want, frankly, as an engineer. It's not as much of a religious war for me. I use virtual box back when Sun had them, it was all right. And there's limitations. Be aware though, if you do this, and this is not knocking on anything. I actually want to push a portion of it to be a KVM native right now. But you see some other stuff on there, gotta do other integrations. But be aware of the default install, unless you do some hacking within VMware to push up the native machine interfaces, it's gonna run QEMU. So if you're doing development down for specific to KVM, you may run into some limitations. So now getting beyond the DevStack installation itself, there's a couple of things that we found that's really, really important. And I think we found this, we're trying to integrate some API extensions into it. And there's a couple ways that you expand the APIs. But there's a file called StackRC inside of DevStack. Inside here, you can do a couple of things. I only showed the start of them here. But you can point it to whatever Git repo you want. So maybe at your company, you're utilizing, you've forked a repo, you're running it locally. I recommend keeping everything up at GitHub. But you forked a load, you can actually point to your own Git repositories. And so you can have the same development methodology utilizing your own Git. You can also point it to, and I'll show it a little later. You can point it to review, which is really important. So this actually happened with that. There's so many changes coming to OpenStack right now that not everything's merged. And one of the things that we found is that we actually coded for about six weeks down one path and found out that a working update to one of the APIs had been published by someone at Intel, right? And actually backed out our code, integrated her code, and we're extending that. So continuing beyond DevStack, and that's where you'd actually take the branch that you're using. And then it points to the working development. So a couple of things, and these are straight out of Van Nuys notes. But little things that when you're running Stack, it uses screen, right? So you can actually, you can kill the sessions, you can switch between sessions. Each of the services starts in the session. If you don't, who knows screen? Okay, good, half you'd be comfortable in this. It's pretty cool, but it's not run in the kind of a classic way. So again, half you know what Git is, so try not to bore you here. Couple of things from the workflows to actually contributing here. So what is Git, it's not like CVS or Subversion, which are commonly used by infrastructure guys. Like so we push files into these things, right? Push configuration files. Git was made by a kernel developer, well the kernel developer, right? Correct me if I'm wrong, it's Linus, right? And it provides like four ways to skin a cat. And it is built in a way that you can be totally decentralized, that you can do development while you're at the lake. In my opinion, for an engineer it can be complex. At least the initial complexities. Now, so first things to get yourself set up. Actually, who runs Ubuntu? Who runs Red Hat based derivatives? Okay, so I've always been a Red Hat guy. I mean, Debin is nice, but I've always been a Red Hat guy and what I've really found is that most of the development I've seen works in Ubuntu first. Canonical's doing an amazing job pushing back to the community. I'd say, at least when you're getting started, stay within Ubuntu. It's probably gonna be a lot easier for you. In that case, so if you haven't installed Ubuntu before, you're gonna come to what the app.git is a tool you use for package management, you install Git. DevStack itself, we already saw the commands, but basically you clone it from the GitHub. GitHub's a website that's up in the cloud. You might say, it brings some code down locally to you. Then you run your stack.shell. Now, next thing you actually, you have to tell GitHub or Git who you are, what your email address is, and then verify that with the configuration list. If you get this stuff kind of screwed up earlier on, we'll end up, as you start going and checking in code, it's not gonna line up and you're gonna lose your mind. This is from a guy who does everything wrong and doesn't read documentation first. Next thing, and who's actually, who's used Garret or Git review before? This is an interesting one. And Vinay, if you wanna grab a mic, so with Git, you're pulling code down. So you basically copy the code locally. You end up forking into a topic branch and you end up mangling it, right? And then you merge it, right? Or you commit it, you commit message and you merge it up. What Git review does is it interjects this Garret service. So there's all, I think it actually runs at HP, if I'm right, the HP clown, the Garret review, the Jenkins stuff. You guys do the smoke test, right? It's complicated. Awkward, okay, so portions of it there. And there's a whole bunch of discussion about, yeah, yeah, totally, yeah, I mean, Vinner stuff is a sign, we're all in the community here contributing code back. We all change our jobs every 18 months anyways. Oh, wait, sorry if my bosses are watching. But anyways, so you install Git review. And what this does with Git is it allows that merge to be forked out, right? So it allows it to go up and be stuck into the rack space, review pros. All the stuff that's running up at a rack space in HP. And that allows it to run the smoke tests and go through run tests and all that stuff. You have to install that locally. And this actually introduces some complications I got hung up on too. Next thing, so who actually, I'll ask you, who develops on the boxes that they're developing on? So you actually edit code in the directories of what you're developing on, versus you develop on your laptop, you pull the code down. So who does it on the same box? Who pulls it down into another location, another editor, like a clips or something? Okay, no one else pulls it anywhere. So I would pull things like into Atlassian's product or what not. And frankly, that's just painful. If you're developing for OpenStack, probably really, really smart to work in the DevStack directories, right? So it's an in-op stack. It'll actually create a directory structure with all the different projects inside, and we'll see if all these things right here. So Glance, Nova, Horizon, Keystone, all this stuff. Those are all the different projects that are inside a DevStack, are the different kind of code groupings, as well as they have the individual tests that are hidden inside of them. It's really handy just to work inside there. And if you wanna pull it into a different editor, you can still, once you've submitted reviews, you can pull that review down in the editor. It's really handy. In this case, I did update to Python Nova client, pulled down and cloned the project down. So I went ahead and updated, fetching the origin, master, and then checked out the master and had it pull. What this did, it actually got my code caught up. It was like 70 commits behind on DevStack one. We got a few servers back there. And then this error. So who's actually faced this error? Who checked code in and didn't set things up and saw this? One. Okay, apparently there's two of us too. What's that? I faced it. Yeah, you faced it. Okay, so two of us. Okay, so this held us up for two weeks. And then Ewan was in, drawn on a whiteboard, and we're like, Ewan, Ewan, come over here. It's like, oh, this is simple, right? For me it wasn't that simple. So I had, mainly it was because I don't read documentation level, right? As in it, it's absolutely in the documentation. And so it's really interesting, or it's not really interesting, it's really dumb, is that it's right there in the docs. However, if you're distributing on a virtual machine, you gotta make sure your SSH keys, oh, they don't put a link. Yeah, there is absolutely no link to where you put, it says how to do, but not what you do. So this is why I put pictures on here. And all this stuff will be on SlideShare, and it'll be on YouTube. So hopefully it'll be searchable, and people trying to face this challenge will actually be like, oh, I can go here. Okay, so you need to create SSH key-gen. So create some RSA keys if you don't have them. In your .ssh directory, you can do this on your laptop, as well as your DevStack VM. And what you do is you upload it to a review.openstack.org. You go into your settings, and then on the left-hand side, public keys. And what you do is just add keys, and you can add a bunch of keys. Or you can keep your C standardized, whatever you wanna do. Depending on how you have key management in your labs, if you're like me and have the nastiest lab on earth, you just, you keep adding keys. So once you do that, so if you see the top, this means that you haven't put your keys up. This was a major barrier. I mean, literally, it was just knocking my head up against the wall. And if there's a get-review-s, if you type that and nothing happens, it's very verbose. It means you're cool. Yeah, this is painful. So, and hope, oh, I'm not knocking any of the core contributors, right? I really appreciate all the work. It's just as an engineer coming in, I think this is kind of the future. It's more of a people like me taking a DevOps focused, by the way, is that we're engineers, we're finding bugs, we're finding things that we need to have enhanced. And then we're spending the time with our limited programming abilities to maybe put it a little different perspective in, push blueprints in, or actually squash bugs or add features. So, making testing and submitting changes. So this I just went over this morning. First things first, if you don't have ProGit, just buy it, seriously. It's on Safari, if you have a Safari account, a Riley Safari, you can download it for free. It is, it tells you everything you need to do. And especially if you get into, if there's some really complex things that Git can do, and you can kind of get yourself into a corner, and what this book allows you to do, and it's not by me, I'm not pimping my own stuff, it really allows you to get through them, especially as an engineer. So first things first, so say you figured out what you want to contribute to. So maybe you want to contribute to Quantum, pretty complex. You want to contribute to one of the different APIs, takes a lot of time. Or you want to contribute to Horizon, which I think is a good thing, that people contributing to Horizon allows you to expose the features that are inherently inside of OpenStack right now. In this case, I created, I'm a Nova client, one of the API, to update something inside of an API. So I created Summit Demo, Topic Branch. What this does is it basically just forks off on one thing that you're working on. And I probably should have called it something different. But inside of this, I went down into the, it's a v1 underscore one API definitions. And one thing I noticed that there were three talks, this three talks I attended already, this Summit that had, we're talking about doing bare metal deployments. And so this is, so I went inside there and it may or may not get accepted, but I extended the definition of parameter vCPU to include vCPUs, to take into account what ITI, or ITIL, I think, no, ITII, the Japanese NTT and what AMD was doing, right? So simple, simple, simple change. Now, when I went down, the next thing you need to do inside of here is the same thing that's gonna run inside of your infrastructure. So who, actually, who gets code and doesn't test it all the time? I'm horrible about it. Here's the thing, if you're actually submitting code for review, you won't get past the first process. So the same, not the, actually I know there's talk of adding fuzzing tests and some other stuff, but some of the basic PEP-8 tests and the basic functional tests of a single dev stack are run using run tests. If you don't pass this, don't bother submitting it, it'll get kicked back, it won't be reviewed. Now, if that does pass those tests, you go ahead and commit dash A, right? Get commit dash A, opens up an editor. Now, if you're working on a blueprint, call it out early in the code. You're probably gonna get looked at, am I right? If you're squashing a bug, call it out early in the commit, call out the bug ID, excuse me, right there, right? And so the reality is there's just a lot of stuff going through the review process. In this case, put a paragraph description. I actually think I didn't, I'm in the lines too long. Again, hung over this morning. So, and communicate what it is. And then you submit them for review. So get review at this point, pushes everything up and you get in the process. So what you'll end up seeing is a website with a review ID at the top, that we'll start, we'll go through and you'll see a table at the bottom, which will be whether you pass the tests, whether it has been reviewed. So this is one of the things about working with the community here, is that if you're working inside of a community and not working alone, you can actually get people to review your code. Because if you don't have someone review your code, it will not get accepted, all right? That's simple. If you're participating in the community, you can get people to review your code. So go ahead and review other people's codes. One of the reasons why we have the ability to pull it to run and test someone's in DevStack, you go and test it out. Partner up with other people, even if they're different sides of the world. Literally, Vinay and I were having a discussion outside of that the developer who we were using, we're passing the extended attributes field in the APIs, she's moving to Silicon Valley. She'll be coming and hacking together with us with the guys at Yahoo and Hackathons, right? So it's really interesting, really useful. So you can monitor the review process, you'll get some emails, you'll get some comments. You have to be aware and track and eventually it'll get pushed through or it'll get abandoned. So if nothing happens after a week, I believe it is, it'll kind of go in the can. Next thing, these things are, so first things, it was what I talked about today, useful, especially those guys who don't use Git. Okay, yes? Who thought that it was utter crap? Okay, at least one of you, come on. I've had one or two sessions. Okay, thank you very much. My friends from VCE, sorry about calling you out. Everyone loves OpenStack, apparently. But, so this is really important to me. This kind of reminds me, back in the late 90s I was running a dial-up service provider, biggest dial-up service provider in Central California, which is like saying the biggest fly on the horse's butt. And at the time, I went BSD and moved to SCO and then I got this install media for Linux, right? And this was kind of changing the way that we did, that we would do our hosting environments, that we would do Apache, do our shell environments. And frankly, it was kind of in the same position. I was lost, I was absolutely lost. And what helped me out was some nerds in the area getting together, the same people I'd quake with at the time, and getting together basically creating some user groups, giving back. And I think this is kind of the missing piece of what people are talking about. A lot of people are talking about the technical aspects of OpenStack this week. But I'm a believer that we have an opportunity, if you look at going from what, 700 people at the last summit with 1,300 people and then gosh knows how many being streamed live, that we've real opportunity to be out and engage people. So, giving back. First thing, the most important thing I can say, you've been learning a lot this week at the summit, and you continue to learn more and meeting people, find people that are close to you, literally, that are in the same region, start a meetup group. Next thing, so Sean Roberts has a session next week. So Sean Roberts is the infrastructure architect for Yahoo. He's the one who set up the SFA OpenStacks. He's been awesome doing the boring stuff, like arranging meeting rooms, getting pizza and beer, arranging speakers, and roping in like the Merantys guys have been there, what's happening is a lot of the architects from Silicon Valley are kind of converging. Set that up. Take the opportunity and be myself. I'm not an awesome programmer, okay engineer, okay engineering leader too. But present back, teach people. One of the most rewarding things that I had this year was presenting to all my design engineers and 30 guys from Cisco. The 30 guys from Cisco didn't even know what they were doing internally, right? They were in the field. They had no idea what Lou was doing or any of the really cool stuff. And I assume that that's the same for, that'd be the same for all of you. Get out and talk about it. Not only learn more yourself, but give you the opportunity to share your experience with the world. We're kind of at the, I wouldn't say at the ground floor. The ground floor's already been pushed, but if you look at where everyone's coming together to do something awesome here, and I kind of encourage you guys to step up and take that opportunity. So with that, on Twitter, my name is at Colin McNamara. You can ping me on Twitter, see if my phone's been going off. I'm probably the most available person on Twitter. I don't have my email up here, because I rarely check it. So with that, do we have any questions about anything, any discussions that we can leave? Yes, sir? You speak, so the question was, what do you do with DevStack with keeping state? So for restart it, so a couple of things. There's one of the reasons, and Vinay has an elegant programmer ways of doing it, right? And I have like a total hack at just snapshot the VM. I mean, honestly. Sometimes when Vinay, you wanna, actually here. Yeah, so and that's when I look at like, I just use tools I know to learn tools I don't know. And whether you're using KVM, Zen, VMware, it doesn't matter, right? You know, virtualizing, you know, using Hypervisor to nest your development environment, it allows, snapshotting has saved the bank in a few times. Okay, come on, there's got to be more. Yes, sir? No. No, I actually, that was one of the things, so when I first came to Meetups, I had already gotten a working environment working, or working environment working. But I had already gotten a multiple environments working, DevStack as well as an actual installed environment using Essex. And I had gone through, there's operational guides, there's developer guides, and there's API guides. And then there's a really old book on Safari that's for, it's only 18 months old, I think. Yeah, but it's just not, I mean, Kudo's for the author for writing it, but it's dated. So you kinda walk, after reading all those guides, I got enough where I could talk about the functional components, how the APIs integrate, what moves where, the process, but not getting through, getting through getting stuff to work, no. I need to be better at that, and that's one, that is absolutely, so if you look at participation, even participation's the meetings here, I think the lowest attended meetings this week are the documentation meetings, and frankly, they're the most important. Because what you'll actually find is all this neat stuff you can do. And a little bit of it's documented, right? And we can complain about it, or we can fix it, right? I mean, this is part of being a community, excuse me? You choose complain. Yeah, no, I mean, we can complain about it, but if you look at, I think, a large barrier to perception of adoption, is actually the maturity of the documentation. Excuse me? Yes, they are. I think 12 people were interested, I check. Oh, that's, and I think they're terribly important. It's really my point, right? Ha, ha, ha, ha, thank you, thank you very much. You know, it's absolutely, I saw that, yes sir? No, I don't think so, it's supposed to be documented. Oh yeah, but if you submit code, there isn't a sanity check they've updated your document. No, yeah, no, that's actually valid, and I think that, you know, and frankly, I should be doing this as I, if I've been gone through in learning, I'm exploring, right? I mean, I can create some web scale networking systems infrastructure, and I get a lot of it, especially when it comes to enhancements around quantum and the storage side. But I should be going through and just poking through documents. As I learn something new, I can do it in the command line, I should be documenting it. So I had to, yes sir? Yes, these slides will be available on SlideShare at the, there's an OpenStack Fall Summit 2012. Frankly, I was drinking a beer out back before this. Yeah, sorry, boss. And then there's also, this will be on YouTube in two days. So, what other questions? Here to help, here to talk. Anyone? Okay, so again, if you guys have any other, any other questions or ideas, you can ping me, I'm at Colin McNamara, I'm on Twitter, if you don't use Twitter, sorry, wrong decade. So hey, thank you very all, thank you very much for your time, your questions, your participation. Thank you.