 All right, I think we're ready to get started So I'll be moderating the panel Thank you guys for joining. I think that the theme that would like to explore in this panel is dive a little bit deeper into the perspectives of the companies that have emerged in the open stack space as businesses focused on Particular aspects or particular projects in open stack. So kind of you know the first wave of Open-stack battles so to speak were around Open-stack distributions that go across a variety of projects But then in parallel there is a whole bunch of players that emerged We have a much more focused strategy and we have some of the folks on the panel here Representing some of those companies And throughout the panel I wanted to give people the opportunity to ask questions. I'd like to keep it interactive I'll tee it off with some of the questions, but please feel free to pitch in And I think that we're ready to get started. So I'd like to thank the folks from to Sora for actually putting this panel together and Giving me the honor of moderating it I think we'll just go ahead and start with introductions and what I'd like you guys to do is Just introduce yourself tell of you think a few things about your company and The two I think things that I'd like you to hit on is one talk a little bit about Your business model. So how is it that you know, you're you're monetizing whatever you're doing Is that you're just selling subscription or you have some sort of? value-added Licenseable product The second is Why are you even, you know doing it in open stack as opposed to actually doing it outside of a community? So Joe I start with you. All right, so it's good. Thanks Boris. So my name is Joe Arnold I'm the co-founder of Swift stack and I was the initial CEO there and so what we do is we focus on open stack Swift and where the the leading contributors to the open stack Swift project and What we've done is we've created a product to make it easy to deploy operate and scale open stack Swift and what what open stack Swift is is it's an object storage system and It's really good for unstructured data media assets Large amounts of storage. That's what that's what we're focused on and So to answer your question around with the business model that we have we're we're, you know, there's a few options when you're an open-source company and The path that we chose is to build a commercial product around that so that does mean that some of our components are proprietary and the other half of the product is open-source and then for that whole system together we charge a subscription license to use the software and What that does is it gives us the ability to have a highly repeatable Deploy base so everyone's running exactly the same thing. There isn't a unique snowflake and that from our point of view what that helps us do is It keeps the cost low for supporting additional customers as they're coming on board and then everyone can benefit from from that the last thing which is why Open source at all versus I guess it applies less to you, but might apply more so to others Yeah, I happen to know that you guys have started with open stack and you were kind of in there from day one and Swift is open stack and you are swift so it's kind of Understandable so you can just skip that part of it. I'll pass on make it easy for you I'm plum grid co-founder and city at plum grid and What we do is we provide a networking solution for open-stack clouds Networking of course is something that originally seems very simple You deploy your open stack in a few notes, but then you start scaling going across Multiple racks multiple air-to-domains then you want security Scalability load balancing policies and so on things become complicated and plum grid provides a networking solution that satisfies The requirements of private and public clouds based on open-stack. We interface through neutron through plug-in plug-in into neutron and The way we started was more as a generic going back towards questions a generic networking layer The reason was because networking has always been about connecting things together and never being in a kind of a Silo that you cannot reach to basically legacy environments being bare metals or via more environments and so on So we started creating this technology that can go beyond open stack But the focus is on open stack now the business model is based on licenses on a per node basis But what we recognize is that open stack is kind of a an environment that gets deployed as a solution Basically has to be the open-side distribution the storage the networking and then of course the the at arms in terms of databases and services beyond that So we tend to be very flexible in the sense that we adjust to our go-to-market partners and open-side distribution in terms of How do we provide a compelling solution for the end user to deploy the full capabilities of the network plus the open-stack environment? Okay, my name is Amrit. I'm founder or CTO of tesora and We're the company which is focused on the trove project for those of you who don't know what trove is it's the databases service project with an open stack and what that gives you is the ability to provision databases relational and non-relational databases and Manage them through the entire lifecycle of the database So it automates things like taking backups or managing clusters or managing replication or If you have thousands of database instances making sure that all of them have the exact same configuration settings at the same time It's a project which is it's one of the projects in open stack and it's a consumer of services from Swift and cinder and as for storage and Nova for compute and so on Why we how do we license the project was the or what is our business model? You can get trove from open stack at org You can get it from any number of distribution vendors like canonical or red hat or what have you? And those are typically the same product which you would get from open stack org There are several things which we've done to improve that which we offer as part of our enterprise edition We also have a community edition, which is literally the same as the open stack org software only easier packaged and easier for you to use One of the differences between trove and the other projects is in order to Actually use a database to service you need guest images for each of the independent individual databases you want so Some companies use my SQL or post grass or a collection of them for each database, which you want you need a guest image We provide guest images which have been built and certified at no charge You can download them and use them whether you use our community product or our enterprise product But we primarily our business model is through selling our enterprise product Which has support for some databases which are not an open stack trove like Oracle and like data stacks and things like that We didn't choose to go to trove we didn't start somewhere choose to go to open stack Trove was the project for database the service. We've always been Working on database the service and we chose the trove project. So we came to open stack rather than the other way So to continue on this theme then the question is why did you come to open stack because from what I know? Tessora has existed before The focus on trove. Yeah, but then at some point you decided that hey, we're gonna really embrace trove and make that our strategy What's what drove his decision? So they'll tell you a little bit of history of the company So Ken who's my co-founder and I got together in 2009 my history was working with databases for a long time and The thing which I saw as a transition So if you think about how people consume databases in the old days, you would buy a costly server You'd buy some costly software Which you'd pay a lot of money to a guy who has a big boat And then you put the two things together and you'll curse and swear for a long time And then you get something which looks really ugly and you call the database And if you did this a hundred times Like big companies do because you have a hundred servers on one of them You forgot to make one little configuration setting another one You forgot to make one other configuration setting and that problem would show up usually Two o'clock in the morning on your wedding anniversary when your phone rings We realize that people are moving away from that model of purchasing databases to databases as a service Everything as a service. So when we started in 2009 the choice of what Platform to go with was difficult. It was either Amazon or EMC at most Amazon didn't seem like the right choice because that was going to be public cloud all the time and the MC at most just Didn't seem like the right choice period So we we decided we'd build the mechanisms to Manage databases at scale and then figure out where the market went in two years later open stack was the obvious choice So that's when we switched over to open stack understood Thank you. So next question to panelists. So do your companies contribute code upstream and If they do then the question is why because naturally not all members participating in open stack are active contributors Tribute many different ways not just code Some choose contribute not to contribute some choose to contribute very heavily Contributing upstream as an investment. You need to know how to do it Do you do it and if so then why? Alright, so we hugely contribute upstream Yeah, so we so what what I think is great about open stack is that you can be a huge contributor to a project but then everyone else can also be a huge contributor to open stack and and So just in our in our project around open stack Swift We you know, we always like to claim, you know put the flag in the ground. Hey, we're the leading contributor to this project We have the project technical lead and that's our those are important things But then you look at the pie chart and you guys put that together and you can actually see it's like there's other companies you see Intel contributing HP and contributing you guys are contributing and And that's that that's great because that means you get the diversity and Buy-in and it's not just like a single company if they're coming along and they say oh, we're gonna go open source this thing Well, is it really open source? you know really you can only go to them for a solution, but I think one of the benefits about open stack is that It's a broad community that creates that level of competition, which I think keeps us all in our game and And but then we all benefit From each of our contributions and what I think is important though is that each company? and I think all of us are in the same boat is we have to differentiate on what we're gonna be good at and For us what that means is we can be really focused on particular use cases specific industries and Go out right after that and we can do that better than anyone else While other people can go and take that same code and go do other things with it like building public clouds You know our path is okay. We're gonna drill into the enterprise and do what it takes to Land footprint there for example But other people can do other things So I'll take a crack at that So at plumber it we had to focus in in multiple projects open sake is one of them Of course we contribute on the neutron site less on the other on the other parts But we have to do a little bit more the thing is that networking starts at the kernel and the reason is that you have a Performance motivations while the packet enforcement lookups and things like encapsulations have to start a little bit below What opens ugly so what we did is from the beginning we created a new a very Programmable data plane that allows you to extend the capabilities of what Linux traditionally does and we had to upstream that so what we did is a Couple of years ago We started a project within the Linux kernel community and we managed to upstream in the Linux kernel that so that was Two years two years and a half effort and this became kind of part of the standard default kernels after the 4.x release trains after we had that though it was not enough because part of our data plane was More capable than others because we could program it with a set of tools and SDKs that allow you to express what you want So we went to the Linux foundation and we created the project call ios or collaborative project by the Linux foundation and Different members joined some of them not working companies like Huawei Cisco Silicon companies Intel Cabio Broadcom and then Distributions like shoes canonical and barefoot networks joined to so what we did is essentially contributing to the community based on the building blocks that are needed to make a Flexible extensible and highly available networking solution and then of course the other component which is open stack that we are more focused on Networking initiatives like neutron courier and things like that So we we have a similar situation as the other two companies here We are huge contributors to true upstream. So in the journal release kilo and in Liberty we were the number one contributor in the last release. We were I don't know 47% or something like that To us it's important that we contribute upstream because People are using open stack fundamental. Well, not fundamentally one of the reasons is because they don't want vendor lock-in So if you go to a person who is already Preselected open stack for that reason and you say your only choice is a closed-source solution your chance of winning There is pretty small Also, a lot of people Brother download software the way in which people buy software these days is different They download the software they try it out and once they like it then they decide whether they're going to pay for it or not So yes, we do contribute upstream but To something which you said we've gotten into trouble for that because trove is a project when it started in nice House supported seven databases now supports 12 or 13 and in less than a year. We've added a replication clustering configuration management Sizing some initial things to do with scaling and so on and we decided we have to move really fast so to release us at two cycles ago We were having a serious problem with getting code in with reviews and one of the things we consciously said was Make reviews smaller and make smaller bites of code. So the reviews are faster So we've got two companies HP and to Sora with a bunch of people working on it And we're contributing a lot of features Not necessarily Enormous numbers of lines of code, but new features, but we break our commits into small chunks the exact same charts which you talked about show us at 47 percent and HP at a little over 30 something percent, which means the two of us together are over 80 percent So we get dinged on the maturity number Which we heard about yesterday. So it's a double-edged sword. So We want to contribute to the open source product We want to make the open source product successful because we're not going to be successful with our enterprise product unless that product is successful But in order to play in that we're getting dinged because the way in which it's being measured Understood. So what would happen if you stopped contributing tomorrow? To your company, is it gonna be bad for you? If we stop contributing to that sort of a panel if we stop contributing to the upstream project Yeah, my view it would be bad. Why? So you stop contributing to the upstream project if we were to stop absolutely be bad because people are gonna look at and say You're you're effectively creating a close or a non open source project, which That's fundamentally not the way in which people want to play on open stack Yeah, so besides half of my engineering team quitting on me Yeah, I think that's a huge part of our development culture is being open and collaborative about Doing the development work. So if we're to do that, yeah, I mean I don't know it wouldn't be the shape of the company wouldn't be the face of the company how we operate so But you know, there would be other companies that would continue there's a there's a lot of momentum behind the Swift project and I would hope we would be missed But I want it it would Look, I mean to do the development in the project. We're taking we're taking customer requirements and we're folding that in and As long as we're getting to do that then the project's going to move forward And to extend on that if we were to stop if you were to stop Maybe there's other companies because Swift as a project has been around for longer Trove as a project hasn't reached that momentum point So today if we were to take our foot out the gas take our ball and go home Then the number of to the sheer number of commits or if you look at a number of engineers dedicated to working on trove We'll drop by a factor of two-thirds That's not a good thing I guess there is a symbiotic nature between Companies like ours that we have a component that is open source But we have a component that is not open source and the community right and the community has certain fundamental shortcomings in the sense of like I don't know putting things at scale or highly available There's still a lot of gaps that have to be closed and the reason why there's this symbiotic Contributions where we contribute upstream to help the community to get better But at the same time to plug the capabilities that we have that fulfill a need for the community in a Better way, so if we would stop contributing would happen that maybe somebody else would pick up the effort that that's a valid answer But at the same time what would happen is that our capabilities with the alignment of the community would start to grow apart Now if most of the business of at least the three companies in this panel are based on open stock being successful Definitely that would be bad because this misalignment or would take one of our companies away from the main part of open stock Or would leave a hole in open stock All right. Thank you. So we've warmed up now. We're gonna spice things up a little bit So most of the questions actually were prepared by Tessora, so thank you, and I haven't seen the question so and It's not me throwing curveballs or anything like that, but there was a question there and I've purposely decided to kind of Soften it a little bit, but the question was are there any projects and open stack that need to be killed but the via Softened version of it is a you know, do you see any projects? Evolving as part of the open stack kind of umbrella set of projects that maybe should not be part of open stack I mean, I have an opinion right so actually I would say no right because I think that in order to have a thriving ecosystem You have to have a place for projects to land and yes, some are going to be successful Some are going to get more mature and others aren't going to be more mature and are going to fade to down to the lower Whatever the lower right on on the maturity spectrum but that's okay, and just because a project isn't successful doesn't mean that Open snack shouldn't be a place for a project to come live and it's a It's a great organization There's structure around how to contribute open source There's and we we talk about even in our in the Swift community We have sub projects within Swift some we feel should go in some we feel that we should stay out but I think it's okay if Smaller projects come in even if they don't get broad adoption just for the government's model just for the way that Code gets development in with an open stack Take a controversial approach I mean we are talking about the living thing right it's code and code Becomes complicated and it returns at some point need to be refactor So the question is what does it mean a project to have to be killed or not? If we talk about projects that are be in the early stages of their life cycle Of course people will say oh, they are not mature Maybe they should be excluded by open stack, but at the same time if they are being created is because somebody Finds a value on them so I guess what has to be some maturity thing like the stats that were coming today in the keynotes of Saying when a user deploys open stack When to know when to take the risk or not now having said that the question is like why at some point We should not I don't know refactor neutron or refactor nova or whatever it is So the question is going to be what's going to be open stack ten years from now five years from now Because maybe somebody wants to write it in something that is not Python Maybe it's language of the future so we'll have to at some point revisit what is to be part of open stack Is it the API's is it the code? Is it the combination of the two is it the message bus should we have a scalable systems that solve some of the Structural problems that we have in the community. So the question I think it's much deeper Which is what's going to be the open stack definition a few years from now and how do we find a way to rewrite things? When appropriate because otherwise we will be stuck with a code that eventually is going to be too old to maintain or too big to To see in the current structure So I think it's similar to what you said. I think it's a self-selecting process The the code didn't just magically appear one day. Somebody had to write it. Obviously that person felt it was useful for something I Would however say that if there's a project which has gone dormant and has not received contributions in a while Changes of any kind then it makes sense to kick it out the side at this point I don't know that there are any projects of that kind But so long as a project is active and somebody is interested in contributing to it It isn't really affecting the rest of the projects by the fact that it's there It's adding some value to somebody let it be there. It's a self-selecting process What I would like to kill is the explosion in the number of API's which open stack is generating There was a time when there was one compute API that was really good now. We've got two potentially three What do projects I'm speaking specifically for trove do is trove supposed to understand three API's for compute tomorrow Or can we have one because the moment you start exploding the number of API's it becomes harder to consume the service even for an end user So let's continue on this thread a little bit more and My question is in your opinion Should the open stack community drive the projects More towards kind of an opinionated implementation of a project or should it stay kind of at a higher level of abstractions and Kind of everybody should agree that open stack Primarily is about the API consistency and you have to have a consistent set of API's And then you can plug in a whole bunch of different things underneath So and in open stack there's different kinds of projects, right? So for example of swift swift is a full implementation, right? You can plug in a whole bunch of things. Yes, but you know You can just take open stack swift and use it and you know, you don't need anything else, right? That's if you look at nova or if you look at neutron, you know There's varying degree of the implementation versus plugability So should open stack drive more towards maybe having a complete implementation of networking Complete implementation of block storage complete implementation of object storage or should it just be all API's with different solutions that are pluggable Yeah, and I'm hugely biased, right? And and I I think it's great that someone can take a single project get it up and running have it solve their use case and That's a great introduction to open stack I think it simplifies things and I think that can lead to more adoption of open stack if people can take a component and run I mean why not have neutron as a standalone thing, right for example And and so my in fact a lot of people do that, right? Yeah, it's like 80% of it probably 90% of open stack deploys We just don't use any SDM plugins just use neutron. Exactly. So exactly So, you know if I were to put the opinion slide, you know all the way to you know to one side It would be let's have a full running implementation of you know specific projects And if you want a database as a service sure just go fire up trove and there it is there's that slice Now that's obviously a simplistic view of the world and there needs to be a compromise in there But I think that's where I would stand because I think that offers Deployers more option and more choice and can lead to more adoption of open stack I'd look at it from the from the end user's perspective and say For a person to want to just deploy Swift and have it solve a particular use case There's a problem and it's solving it now If there's a person who says I need databases of service Don't drive me through this mud and grime of keystone and cinder and swift and glance and Nova and you know Three other things which I didn't mention Just give me the trove appliance. I want databases of service make the rest of the stuff part of your appliance for Christ's sake I want database of service you do all that stuff. We're actually working on something along those lines My take is it depends on the use case right open stack is trying to serve from things in service providers for network function virtualization to other things like IT clouds to other stuff So the notion of an opinionated Implementation always comes with a premise that the person that had the opinion understands the use case and tries to satisfy That use case if the use case become diverse now What we end up is with a mess because maybe you have two or three opinions that that I to agree in the middle and Implementation doesn't satisfy neither of the three opinions that were there So the other option is okay fine Let's create a modular implementation that you can plug in based on the specific use case that you have something like a more secure networking solution that the default one because this is for a for a federal federal government organization versus a private cloud in the garage in your home, so That introduces complexity and testing and continues integration and things like that So the the notion of having a default option in open stack where you can jump start the cloud I think it's almost there I mean even with neutron you can do many things with compute nodes and networking nodes that may not scale or may not be completely High performance, but it's good enough for most of the people Should we focus on the areas that there are problems In terms of based on the requirements of customers like high availability and scalability That network is a fundamental component have a better implementation maybe and Now this I would take it back to the use case saying but now you have like service price saying this should be the PDK versus Linux kernel versus something else. So I think we are humans and as humans choice is kind of Fundamental and I think it's going to continue to be a driving force of open stack being a community where things come together Rather than strong mandate by somebody saying that there has to be only one way So if we then take Joe your opinion Which is an interesting opinion and in many ways I personally do agree with it Do you think that it makes sense for then open stack community to start just straight out forking some of the projects that? are historically been used as Plug-ins because for example if you just add on now There's a you know a whole ecosystem evolving around Magnum and a lot of stuff happening of Kubernetes with Kubernetes its own community They have an roadmap so Magnum community might want to go somewhere else, right? So if you want to really have a full implementation Ideally just go ahead and take Kubernetes and just fork it under the open stack umbrella You can say the same thing for Seth. You can say same same thing for neutron and I don't know Open-con trail for instance and you keep going Is this something that Would make sense or no? I Think if you look at the Linux distributions in the past What happened is that Linux kernel maybe one, but then you have differentiation on what version of the kernel? What patches for security and resiliency what user interface do you put what packages? Do you fit so here the distributions like Miranti is and others? there is an aspect of self or natural selection on what it works and What's going to happen is that yes Somebody has to take this notion of putting all the pieces together and making it work And if you call this for king it or customizing it or creating something that is supportable It has to happen because you cannot just say everything that has been Upstream in OpenStack you are going to take it as it is and support it so the The distros is the place where things will kind of have to be supported and come to life And in the same way as in the Linux desktop They had a major role to make Linux adopted in the OpenStack wall. It's going to be something similar So I'd go in exactly the opposite direction because in that area database the service is different from the others you may have You may choose to have one plug-in only in the others But typically a person who is using database the service is using it because they're using more than one database If a customer is only using one database database the service becomes less attractive to them At least trove becomes less attractive to them and most customers and most complicated applications these days are polyglot persistent You are going to have some data stored in a no SQL data store some data stored in a Relational data store in some cases multiple of each Therefore forking it and saying trove have a trove my SQL and trove have a trove something else Becomes much less attractive because at the end of the day One of the big value props for trove is to say no matter what database you want The API call to create is the exact same one the API call to resize is the exact same one So the fork will actually destroy that value problem. That's right But the other side of a value prop that you could offer is you can say that Here's a database as a service that works really well out of the box and covers 80% of the use cases For relational databases, but is just this one thing So we had so that if so Amazon database of service is just one, right? So it's not like they don't have multiple and people are using it No, no Amazon RDS is multiple databases. You have my SQL you have Postgres you have Oracle bring your own license You have SQL server and then they have Dynamo DB and then they have redshift Okay, so so they do have the same spectrum so in that regard storage and database are slightly different But to your other point I'm gonna make a shameless plug We have a product which will give you 100% of the databases and do it really well with that. It's not open stack trove It's our deep-ass platform. So that's the distinction again where we want to differentiate our product and say You have a requirement for multiple databases. We've got a product which will address that. That's our differentiation Okay Very good. So let's switch gears maybe a little bit before I continue of my questions anybody in the audience has any questions Okay, there I go Zero, I mean, it's always good to be For us it's more the certification of the different distros because customers care about how am I going to install? How am I going to upgrade? How do I know that I'm not going to have conflicts between the open stack choice Open-stack distro of choice with a networking choice, right? Especially because Networking is kind of glued to the whole thing. So for us what we've seen more is like the question of Do you work with this distribution rather than just the open stack test? Yeah, it'll be a little bit less short It's about supporting the applications and the use case and fundamentally as a business as a startup someone who's building software It's not about no one's coming around going with a checklist of do you support? You know all these things that the open stack foundation says that should be in it By the way, you know it is we do right because it is the project itself But what they do run around and saying do they do you solve my use case? Do you solve the problem that I'm having? Can you to be deployed can I operate you right? Those are the questions that customers are asking right? So it's less about you know, how do we conform to some? Standard right, I know back in the day I triple E or Cina or any of these standards really what customers are caring about is Can I go to them and solve their use case or their problem? And you know to the extent that certifications can matter it's not about open stack certification It's about the layer above right so You know getting certification with backup utilities and you know these are other applications that people use for example Those are way more important, you know as we're building our business For for users for customers Yeah, so we're in the same boat as your first answer zero nobody cares about deaf Of course for strobes concerned what they do care about is do you work with pick a distribution? Do you work with maranthus distribution? Do you work with red has distribution? Do you work with canonical next question? Do you support this database? While troves come a reasonable way, and we support a whole bunch of databases. Do you support MongoDB? Yes, we do. Do you support clustering and Cassandra? We support it in this release that do you support neo4j? Sorry, but if you pay us enough money, we'll make you do it That's so number of people who asked for a deafcore test zip, okay? So is another question Can open stack ever catch up to AWS and does it need to yeah, I was just after I was gonna add that stuff I started talking about what they should it like really really like can is I mean so people are choosing You know public cloud versus, you know private cloud for almost entirely different reasons, right? It's not it's not about having you know mirroring the functionality. That's in AWS and by the way We don't know what's popular in AWS. Only AWS knows that what's popular You know, there's maybe a ton of services that are complete bombs, but we have no idea But we do know which projects people are using in these private deployments because we can see the projects that are underway Which ones get a lot of contribution and which ones are moving ahead, so I mean yes Amazon is a absolutely a runaway freight train in terms of consumption of infrastructure resources, but there's Great reasons why people are doing on premises and they're making that choice almost independent of whether they're going to Amazon or not So I don't even know like it should we I don't think the answers should be yes So the answer is that we can't get you up, but it doesn't matter. It doesn't matter correctly Yeah, it doesn't matter. I don't think but I don't think I think catching up is the wrong question to ask Because it's not about oh do we have redshift in opens? I mean, maybe we have something similar but What people need in order to build the applications that they're doing in the Amazon's ecosystem is not the type of things that people are necessarily doing on for on-premises deployments and The only way that we're gonna be able to suss that out is by actually going into those environments where they need the on-premises Infrastructure and then building up solutions for them based around that. They're not in Amazon for Very good reasons. So what's capitalized on that? so I So I'd ask what you mean by catch up with Amazon if you're asking in terms of total terabytes of storage total core counts So on absolutely. It's perfectly possible. Yes, it's a good that the next thing which I'd ask is if it's in terms of diversity of projects Absolutely, we've got more projects than they do. There's no question about that But is there one thing which Open stack can do which Amazon has no chance at this point of catching up on yes, I Have my data center in I have my data in my data center Amazon beat that You can't which Maybe it's not the right question right in the sense that Amazon is a service when you take open stack is something that then you Have to run by yourself Now the question is do you buy support do you train your people and I would say the kind of the first comparison would be When people move from BMO air to cloud do they create their clouds or they go to Amazon because this is the kind of hard choice Do I keep the existing business models at the lower cost or do I shift into a cloud consumption model? And probably both will be viable and this is like in any technology. We had desktops versus VDI and There's going to be a combination of the both where a lot of people for security reasons on data ownership They are going to keep it locally But they'll need something that is not as expensive of the current choice and some people for convenience We'll just go to a public cloud because they may not have the expertise to run their own private clouds Yeah, so I wanted to kind of qualify my question. I think that the most important yet I think ultimately To echo kind of Joe's sentiment again I think that ultimately what people care is about the it's a whole user experience, right? It's not the features. It's not necessarily you know Stability is definitely a big part of it But what you care about is, you know, I have my applications I want to be able to run them fairly easily on my infrastructure platform And I want to kind of not have a big headache. That's ultimately kind of the goal So by catching up that that's what I meant that that was my kind of question Here's another very concrete kind of way to to ask the same question. Maybe we'll kind of repeat so There's rumor on the street that Amazon's gonna launch a private cloud in the box service You just have like a container of AWS that they just ship and they just put it in your data center You have everything that AWS has just a stable and they just remotely operate for you But it's right there and you can burst to the public cloud Is OpenStack dead then? They've been saying this for a long time Yeah, okay, but once we do it What happens? Yeah, so okay, so Okay, now you're putting all your stuff inside of AWS and all right You go talk to the IT folks that we're all talking to at this conference The lock-in is just incredible like especially with moving the data like you mentioned moving data around that's They're gonna have your data and now you're building your applications tied to that infrastructure suddenly becomes this operating system and you have no other place to go and I don't I think that we have to as an industry kind of draw a line and say look no We aren't just gonna go around and commit all of our applications to one company I mean, that's why we're all here and we flew on a plane It's some of you're maybe locally in Japan, but we flew here because we believe that There should be options and there's should be an open infrastructure that people can deploy into and I just don't see everybody just moving down that because of oh well It's convenient and they can park a shipping container in my parking lot I think there's a real belief that people don't want to be caught up in being locked into the same vendor Because once that happens They're gonna have you for life and it's gonna be hard to get out They have you for life and they have your data and you don't necessarily know where it's going Do you have a mic or a linux machine? So it would be a very very interesting situation because it will depend on the cost If it's cheap enough and they manage it for you a lot of people who go for it And that's why open stack has to improve much more in terms of the operational tools and how to understand How to troubleshoot the system because at the end of the day from a financial point of view if you have the cluster in your data center It's easy to operate. It's cheaper. It would be a challenging thing for the industry Now is all the things that you said completely true absolutely because then it's going to be much easier to migrate between the public Amazon and the private it will never go to Azure or to Google and you start to being locked but It's it's going to be an interesting thing. It doesn't your isn't your implicit assumption It's a zero-sum game that if they go to Amazon, they're not going to use open stack. We use open stack They're not going to use Amazon. We're talking to people who want to use hybrid cloud all the time They want to pick up trove and say hey trove. Can you provision an instance in Amazon AWS as well for us? So yes, you're going to get that shipping container some number of people are going to look at the cost and say put the shipping container there Doesn't mean they're not going to have open stack as well They're still going to have Miranda's distribution running right next to that shipping container and your software and your software and ours yet I hope so absolutely I can't it's great to always have your colleagues do via, you know, evangelism on your behalf I'm actually taking notes as a marketing guide to Help kind of propel the message. So thank you for helping Oh my gosh, no absolutely right and that's part of the choice that that that is out there I mean, you know folks like NRIT here in the audience they they run a public cloud based on open stack and that gives that gives cloud providers that option too So I don't I don't think it's just private. I think from a if you're talking to someone like like like us are We're focused on More on private because it was more type of enterprise customers and yeah, there's gonna be a certain segment of our customers to us It's a single customer. It's a they're running up on premises for them But they just happen to be offering that as a public service But I think it's more the mindset of someone in our shoes Building software and selling software to companies see other other have that's interesting right because with open stack You have the option of managed private cloud So time check so last comment So some managed private cloud is something which is already there effectively by putting the shipping container in your in your data center Amazon saying hey, we want to get in the managed private cloud But the number of people deploying managed private cloud with open stack is staggering So that's that's a good thing for for open stack. All right guys. Thank you very much I think that there's we're done one time, right? I think I I think I think we're just people piling in there So yeah, thank you All right All right, that's better The slides are at that bit leave you like to follow along our private reference for later Thanks Matt. Yes, I have atrocious spelling. I know that's why that's why Mark mostly I speak JJ. I don't speak English Hello, welcome. Hope you're having a great conference Hope you're here for the what's cooking. This is a deployment and With the chef and the open stack cookbooks. So I hope you hear to hear about that. Everybody can hear us. All right. It's all good. Okay We'll start off with some introductions Hi, my name is JJ. I'm that guy. I'm a senior partner engineer at chef. I Am the open-sec chef guy Anything chef related and open-stack related usually gets funneled through me at some point technical resource So my name is Mark van der Wiel. I'm from IBM We started using chef a few years ago when we got involved with the open-stack project They seem like a good pair to put together So I've been working on the project for quite a while now and I'm one of the cores so what is chef if you don't know it's a application to be able to provision and Control your machines from a centralized repository. It's infrastructure is code. Everyone know what chef is so I can just kind of Know yes Okay So as it says some of the simple concepts are it does I don't put it does uses idempotency and also You'd have state-driven Code to be able to make things happen. So you can say yes I would like to into package Vim and you run to the chef client and installs Vim for you and it uses as I said infrastructure is code where you can Control things called cookbooks that I like I'm going really off the topic here So as you can read It automates and how applications are configured deployed managed across your network no matter the size The advantage chef has over a lot of other configuration management systems is that the chef client is run on the Compute note instead of on a centralized server. So you don't need to expand your Master of puppets if you will to be able to take a blob back and forth on the machine So I'll get into what do you get with the current where we're at with this project? This is part of the Big Tent Everybody knows Big Tent, right? That's the core projects and everything outside the core projects is part of the Big Tent The open stack chef cookbooks are in the Big Tent So you can take a look at them where we participate in the community like everything else So what do you get with it the the thing that with this project that was key to making it whole was Of course coverage of at least those core Projects in open stack Nova Glantz sender keystone all the rest of them, right? So having support for those so you can lay down open stack with that type of deployment was the goal of this main start of this of this project The other part about this is is keeping the overhead down on your nodes, right? So you don't want to have a lot of infrastructure on your nodes to be able to have to manage these nodes So these nodes are managed via chef and its chef client is called. That's an agent that runs on the nodes The biggest thing that I think that's most important if you leave this room out of anything else is to understand what distinguishes a lot of the chef Design concepts. I'm a designer. I'm a coder, right? I keep designs in my head more than I keep You know ads in my head of other things is the the the idea of being state driven Okay, this means you run something, right? You run it again, and you run it again Every time you run it the state will be the same It's hard for people to grasp that because most people don't code that way That's not how code is written. That's not how scripts are written scripts written You run the script. It doesn't work if I run it twice Oh, you can't run it twice without deleting this first that kind of thing all the Backlash you have with running things more than once the whole point of this is trying to be a state driven for your node management and of course the other thing about it is that the community has come a long ways with with our Cooperation with getting into the big tent as well as moving along with our testing So we think we've done a pretty good job moving the unit tests in forward with these cookbooks So that they're relatively stable And I can add to that also Chef is Ruby. It's not puppet. Oh, sorry. Yeah, not not Python. That was Freudian So we have TDD our test-driven development built in if you ever use any bit of Ruby at all One of the tenants of Ruby is test-driven development So we have unit tests and they are actually RB files So you can run actual our spec or we call chef spec Which is a level on top of it of our spec to be able to verify that when a converge happens Which is what a chef client does you it comes out as a state you you expect to have so you can have You can create a CD CI pipeline using the testing So when you're moving through your your changes i.e. creating an open stack cluster You can actually before even running it on a physical box or a VM You can verify that the thing will come out how you expect it to come out which gives you confidence and Your changes to production because it will catch early on in the pipeline So the next thing is okay why would you step up to this versus other types of deployment mechanisms and The one like you mentioned before is is the part of this infrastructure and being tested before you move it the cookbooks Have resiliency in them that to drive drivers state-driven deployment of your of your open stack clusters The other thing is that I think is one of these it's a good and bad thing and you'll see it later in the slides is customization Right. This is a fully customized solution right you can extend it beat on it twist it turn it and it does have a The ability to be conformed to what you really want and that leaves it as the last one right that it's It's customization, but it's it's it's beyond customization of what opensack wants right you can custom customize it Also with how chef works chef allows itself to be easily expandable and wrapped if you will with other Other solutions that can go with it. So it's not only customizing that what you do in your cluster But cluster but also customizing your management solution. So that's things that some other things don't quite do that much for you Talk about a community. Yeah, absolutely. So one of the strongest things chef has is we have a huge community online to do to create what are called cookbooks that are Literally right now a collection of recipes to do something anything ranging from building an open-stat cluster to installing them to controlling system D and everything between The there's something called the supermarket, which is supermarket dot chef that IO which is not on that slide We should have put that there Which is a collection of places for cookbooks. So if you have your laptop in front of you probably want to check it out It's a great way to share cookbooks and have things out there so with the cookbook community we have volunteers controlling the cookbooks and administering them and there's a certain level of You can have gradients of Quality of cookbooks, but most of them are that are out there do what they say, which is amazing And it's all completely volunteer driven. So which is great. Oh And yeah, we should say that too because yeah, we are part of the big tent We do get a TC. I have verified that So if you do commit to our cookbooks, which as part of the open-stat community, you can go through the normal Garrett process and You will get a great TC So here's a slide that kind of tell you you know the nuts and bolts here about you know There are good things and there are bad things strengths and weaknesses. So One of the strengths of that I think is one of our most important goals We've been trying to focus on is being production ready, right? So we have the test cases behind to verify that. Yeah, we can actually use this in a production environment Speaking as an IBMer. We have used this in three products already. It's shipping. It's out the door It's in the community. We've shipped it to hundreds of thousands of customers already, right? Underneath the covers of customers don't even know that it's being used the chef serving clients under the covers being used by our clients hundreds of thousands whole bunch of them, okay so the Instances Customers are there. Yeah, and then like I mentioned before for in order for I've been to do that We had to extend it with our own IBM wrappers because we have some things that we do slightly differently But it will we are able to do that with these customization with the wrappers And of course the platform dependencies was key for us, right because we decided to use Red Hat for our our enterprise solution for the platform of choice for the internals of our of our products And we were able to do that these cookbook support not only the Ubuntu and the conical side It also supports the Red Hat side and which is very important and and and some Sousa's still in there Sousa if you got Sousa's expertise, we'd love to talk to you. Yes, we would and of course you mentioned the supermarket cookbooks Third-party cookbooks are essential, right? So we don't develop the Apache cookbook We don't install Apache. There's a cookbook that does it for us that with that doubt in the community, right? We don't do some of the database my sequel. There's a cookbook for my sequel That's used by part of the open stack cookbooks to give you the total solution And of course like I said the community strength we've been doing a pretty good job I think becoming part of the big tent and moving our community forward as for wheat mixes We still believe that our cookbooks are too complex for most folks It takes a while to bring themselves up to speed to understand the concepts Not that they're hard. It's just we have a lot of pieces in place It's kind of like a puzzle you can put it together You will see the picture when you're done But there are a lot of pieces and can I interject something real fast? We have our pto. We have a new pto John come on up here. He wanted to talk about the complexity and what we've decided to do for this next release Yeah, hi Yeah, especially for these weaknesses the complexity is I think that's that's one of the biggest problems. So As Mark and JJ already said There it's easy to Add something like wrap cookbooks Add a lot of community cookbooks Add another layer to that via Environments roles whatever so you can really easily customize what you're doing there and we did that for some years now Which in the end right now put us in a place where we really have a lot of layers Where you can configure everything But that makes makes the whole thing very very hard to understand And although it's basically has a lot of switch cases for all the platforms You can deploy red add and susa and you can use MySQL and postgres and db2 you can do the no no no You can do the the the most the craziest things with it, but it's hard to understand and we want to really bring that down to being to covering the most cases like The most cases that or this this idea of covering 80% of the cases, but with 20% of the code So really really putting out all of that stuff that is not needed by most of the customers And moving that to somewhere else. We're still talking about that. We have more tomorrow We have a session where we will talk again about that, but we really want to make it easier to use these cookbooks and to Yeah, throw out a lot of code Thanks, John. Thanks, John Yeah, and the bottom one on there, of course, like you mentioned before is this is ruby code So obviously if you don't know ruby, but for me, you know, I've coded in how many different languages, right? To pick up another language is not that big a deal. So if that's your stomach block, then I think you got other things to worry about The other part that I put on there is individual projects the cookbooks is not one project Like the rest of the cookbooks. There's nova and there's nova No for the cookbooks. There's a separate project for every corresponding project in Open stack. So there's a nova cookbook and cinder cookbook and so on So that also tends to lead to a little more confusion because there's you have to manage more projects Ah, yes So this one right here I figured I would bring up pretty early on in the conversation because a lot of people wonder So why not use ansible? Why would you use chef? Well, not only as a chef employee, but as a community member of our community I believe chef is a Superior product for this because if you've ever tried to do an if statement instead of a yaml file I want to meet you and buy you a beer Because I haven't been able to figure it out There the the way the tasks are run inside of ansible and the playbooks that are run it are very it's the How should I describe it's it's not idempotent. You can't rerun it You can't verify the machine is in the state you want it to be in chef. It's all built in The chef you can actually as mark was saying earlier inside impotent You can run the chef client as many times as you want to get the desired state Ansible you can't do that ansible you run once and then you hope that the compute node pops up inside of Inside your cluster Could they continue on that flame war here? Yes, exactly. So why not puppet? Have you looked at the puppet manifest recently? um so even infra as of this Summit is talking about using masterless puppet or puppet to do their deployments So the major thing it is literally called a puppet master where everything stays, right? And it's gotten so large for infra that they can't run it on a puppet master anymore because all the compute happens on The puppet master unlike chef what I said earlier where the compute is actually done locally on the box That it's going to be told to do the thing. So it's a scaling problem there with chef you can do Thousands and thousands of nodes But there's a point in puppet where Your puppet master will fall over and then you have to build an infrastructure around your puppet master All of a sudden you have three or four boxes as a puppet master The chef server is just in essence a s3 endpoint where it pulls down make sure the it's in the state that it needs And then converges everything locally I'm sure we'll have questions on those two for you. Oh, I bet so keep those in mind So let me go into a little bit of the details of of of how this thing kind of works when you actually run it So there's the the notion of a chef server And the chef server like I said is basically an s3 point It's basically your your data point for all the information that the chef client would need Which would include cookbooks things we call environments that describe your topology Things that um the roles that describe what's within your topology I have a database server. I have a compute server. I have a network server And then you have data bags or basically containers of of low level bits of information like how are you going to set up your User at Eastern passwords are they're going to be just floating around on the clear in some script file somewhere No, you want it to be under control somewhere and and gather together So you have all your essential information at the server level The client is basically then just a user of that information to set up your to move your client Your your node into the state you you described up above So if it's supposed to be a network client, it has a network role It runs the network role with the recipes behind that and boom you get a network client Underneath the covers there are some other pieces that the chef client uses and one is ohai ohai is is Is another really cool thing I think that distinguishes chef and how we do things different than other folks Is that it discovers the basic information about your node Where other I see other clients they have to go out there and do this manually or have other scripts to do it It ohai will know some of the basic information about the node the ip address How much memory it has how we see if you use it has all these little pieces of good information are Pulled right automatically into your chef client infrastructure So it's kind of nice to have it there because then you can base your recipes off of that And I'll talk one more here and then I'll turn it back to uh Jay on the other one So we basically have this this this is the projects that are out there today So we have something called the chef repo. It's our gathering point to bring all the cookbooks together Like I mentioned we have separate projects those projects are called cookbook open stack common is A common one that we have to kind of put some common code together and then cookbook open stack Nova computer whatever the rest of might be these are specific to those particular ones And then of course we have some other cookbooks we we we bring in We have some wrapper cookbooks just in our own implementation to wrap or around the database or wrap around the messaging server Because we don't know what messenger server you might want to have do you want rabbit or you want something else The database do you want mysql? Do you want prosgres? What do you want? We don't want to hard code that in our cookbooks anywhere So we've we've wrapped the community cookbooks that support those with our own wrapper cookbook So you can kind of see this hierarchical thing starting to form in your head, right? We have the repo we have all the project cookbooks and then we have some specific cookbooks that wrap even community cookbooks So it's quite that scheme of how that how this works, but it comes together with the repo So the open stack chef repo is the thing that if you have any interest at all in this This is where I'd probably like you to start This is it's an all-in-one Blob of the data you need to build an open stack cluster on your laptop. So if you have a Ideally 16 gigs, but you can get away with eight Um Vagrant and virtual box you can actually we have rake tasks and documentation on how to build the With using the community cookbooks on your local machine A open stack cluster. It can be all in one or it can be multi-node. So you can have multiple compute Compute nodes after it with a controller with the network node inside of it even has new it has neutron support also It's uh, if you in essence it's chef stack, right? It's dev stack running with chef and it uses uh, right now the packaging from upstream We haven't done it from source yet, but it is we are thinking about going down that path The second bullet point is also important Basically There's a lot of people out there who want to just have an all-in-one build or they have an extra desktop Sitting beside their their computer or they've deprecate or depreciated value and their desktop and they're getting a new one But they still have 16 gigs Well, we have documentation called all-in-one bare metal dot md Uh inside the chef repo that will actually teach you from absolutely nothing to having an all-in-one build of Kilo right now. Um From the ground up. So you can add even teaches you how to use hosted chef and all the major, um portions of the chef ecosystem So you can actually see it we're planning on adding Multi-compute to it also so you can horizontally scale out with multiple compute nodes and then also Off of that i'm planning on writing some documentation on how to teach you how to use the cookbook Test kitchen which is a part of the chef ecosystem with that compute with that open stack cloud that you build So some nuts and bolts here about how how this kind of works So the first thing is well if you're a developer and you want to get started What do you want to do the first thing right check out the chef repo that project is the umbrella project that brings all this together What do you need on on your laptop to get this thing going the cool thing about this? But I think is another thing that you know I can debate python ruby you can do that all night That's fine. I'll have beers with you want to talk about it. I think it's great It's a great conversation There is this great new thing that they came up with that chef that's called the chef decay It's a development kit that encompasses more than just chef stuff right it puts ruby inside there and some other tools inside there So basically if you install the decay you've got all the things you need You don't have to go searching around and try to figure out what other packages you might need to install They're right there and in ruby they call gems by the way Can I can I just jump in real quick? Yep And with the chef decay it actually for instance on a mac or a windows Or sorry mac or a linux box it's installs it under opt so it doesn't mess with your system ruby It has its own embedded version of ruby and everything so it's its own Entity so you don't have to worry about dealing with gem files. You may have heard back in the day of a chef or whatever It's all self contained right so that that's a big key that you can start it right now And it's not going to you know blow up your laptop or like that It's pretty straightforward stuff and then of course I mentioned like you know Linux windows mac is all there for this to get your development started whatever you choose The other part that we've been working on really hard in the last couple releases is testing Testing is done with make files. This is a ruby make file that runs We have our standard tests like almost all the other projects have some type of a lin test style test And of course we're working really hard to get unit tests to be fully complete. We've got quite a bit Unit test coverage right now. The big thing we've added lately is integration testing, right? So we're actually you know, you know eating our own dog food here, right? We're making sure and that we when we run the test It's running against the actual the actual stack that we put up there. We call chef stack So what we're doing there is we're actually staying up our own all in one inside Inside infra as a gate and then checking to make third the basic things work with tempis things like that run some basic tests Make sure things are up and running so that that's that's been a big thing It's kind of cool that now we're actually where we got gates that are running like the other like the other folks In in infra you'll see everybody else is running dev stack to set up their Their open stack and then running tests against that well that obviously defeat the purpose of using chef to do this So we're setting up our own stack in the gates, but chef stack So that's clear, but that's what we're doing and that and that was a big leap forward So we're taking care of making sure that when things change we're testing it as at least for the first part for the all in one Just to continue on with that We did this just recently over this last cycle We started this in vancouver and we were joking about it At vancouver saying oh, this is probably going to take us a whole cycle to do it But as soon as we sat down with the infra team We discovered that it was literally just us Hooking some things up and all of a sudden we're able to build Everything we can everything we want locally and this is important because any change that you put into the cookbooks Any attribute change anything you do We have a non-voting job that makes sure everything it verifies and then we even as we say run tempest after it So we actually verify that the machine that we use the the opens that cloud You just built and made the changes for tempest passes Granted we need to better better tempest tests, but we'll we'll have that sales pitch in a little bit So there's there's some other related products that Is the owner of so he'll let you know about those real quick. Yep. So we have these are the three main integrations From the chef ecosystem into open stack. So instead of the builders of open stack consumers of open stack We have a knife plugin. This is knife open stack Which basically is the major I want to spin up a machine inside of Inside of open my open stack cloud We have kitchen open stack which allows you to use the kitchen driver Which test kitchen is the integration testing framework for chef to be able to spin up multiple machines or one machine Inside of your open stack cluster or cloud to make sure that it shows up how you expect it to and then we have chef provisioning fog which is um a little bit more It's a resource to be able to declare clusters and multiple machines Inside of your open stack cloud. So if you want to spin out three machines and make sure that three machines are always there You can write using chef provisioning fog to make sure it shows up how it does You haven't seen chef provisioning. Check it out. It's pretty cool. It is So just some references here that you know like the other projects We have a wiki that we've been trying to update and keep the documentation there for the basic development How to get started how to contribute how to help out we have meetings Of course, they're right there We have an irc channel come and talk to us and of course we are on launchpad like the rest of the projects All of the projects underneath I mentioned before the repo all the specific cookbooks are underneath one launchpad group called open stack that chef So now we'd like to um, I'll leave time here. So you guys can ask your questions about where we're at and and where we're going We'd like to have a conversation because you know There's a lot of people out there that believe that chef is extremely complex Challenging to use and we like to have an open discussion about it. See what we can do better or maybe stumbling blocks or anything anything Paulo i'm looking at you buddy No, go ahead matt What is the coverage for the various open stack projects? I mean do you have heat morano all those other things? That's actually a great question. We probably should have put that in the slide. Um, so we have all the main core projects and the this release i'm planning on getting magnum and uh Was it manila? I decided or was it something else Manila um those two projects, but all the core main projects you can totally build off the ground um And that includes heat and the heat was it's not part of the circle They short on their maps now they move they moved heat moved outside, but he is already there orchestration is there um, and then uh, uh, uh, ironic bare metal is there Boo So we have those there, um, and we also have some docker integrations parts there too So there's those other pieces are are already there Um, and then there's starts for cookbooks for both trove and sahara. They're started, but they're definitely not complete yet So that's if you're really interested in those let us know we can we can help you work on them I don't think it would take that much to flush those out. It's just that has not been our priority at the moment We are trying to make the priority has been The priority as yan was saying during this next cycle is to make this more accessible to more people We acknowledge that these things are complex And we are trying to make it more accessible to more people so they can just build an open stack cloud how they would like to build There was a question back here Sorry, I joined a little bit later, but We we are using in my company. I'm working for a german telecom We are using a lot chef and the main problem we have is How to package The cookbooks how to manage the life cycle of the cookbooks to to get them through a development to a qa pre-production production environment and to guarantee That the cookbooks that were used in one Phase we are the same in the next phase. How do you manage this? So there's a handful of different ways Off the top of my head. There's just simple version and pinning to make sure you're adamant about your version version pinning There's also policy files Which is another option which we are not we don't fully support inside of the open stack chef project But I can take that conversation offline with you But in the when it comes to open stack chef the version pinning is how we do our things Master right now we don't version because we're constantly moving it forward, but as soon as we Stamp something a stable qo stable, whatever Then we start we have a very strict Sumver policy that we actually put inside our wiki to just to Tell you to make sure that you get exactly what you expect to have So we take version pinning pinning quite seriously Yep for the for the ibm project that we worked on We did it a couple different ways But the main way we had it is we basically had our own Copy of the repo and we had our own locking mechanism there to lock to the commit levels In addition to just the the version levels of each cookbook for every branch of the product Yes, that means you have quite a bit of branching going on But none of those branches though were were forks. They were just branches pointing to something in the community So that was the key is that we weren't forking anything We were just keeping track of okay We shipped out a patch and it used that set of cookbooks and we could track it that way And then on the internal side We could use that as a tracking mechanism right to Fuller understand when something goes wrong People can bring down the exact set of code again and and and take care of business If you want to know more about that I can I can talk you offline about that too Okay, uh, one of the traditional drawbacks used to be the complexity of installing the workstation In addition to the server and bootstrapping the nodes So what's the difference between the old chef binary the old workstation package and the new chef dk one? What exactly does it make simpler? Absolutely. Um, so the chef dk is If you actually go to the old workstation wiki page, which we've been on is still out there, which we need to fix Um, the chef dk is everything you need in that workstation as one binary So it has all the testing all the ruby everything locally there that you need So the workstation in essence is just a install with that It makes life much easier and allows you to get everything you need to go off get get off the ground as quickly as possible The the key management can be answered in two different ways If you're running off of hosted there's actually a getting started button now That gives you all your key management you need and even read that creates a validation key for you um, but if you're doing local or are doing a, um On-premise chef server, uh, you would actually use the same process because hosted and the on-premise server are the same thing now Yeah, just to iterate too that what happens during our integration test, right? It's uh integration step one load and and install chef dk Step two run the run the test. I mean that's that's all that's all it is There's no we don't have to worry about whatever else is on the machine Just run chef dk install and then we start running our test. That's as simple as it is So it's it makes it very nice Though that's right. Yes. Uh and in 12 one of uh chef You don't need a validator pen because it uses the user user a user name to validate against it now And and you can see some examples in our repo about how we put together some of the The data bags and and and how we're using the keys just in there. Uh, it's it's a way to get started so They all in one build um all in one Bare metal build that is inside the chef repo I would I challenge everyone to go take a look at it and attempt to try it Um, I've had multiple people go through it and be extremely successful with it All you need is a desktop that or a machine that you're not using and you'll be able to build your own Open stack cloud in about 45 minutes um With all the configurations and then as soon as you understand it all you can actually blow it away start over again and you'll have it in less than 10 so Less than 10 minutes that you can have an open stack cloud running keela right now. We'll have liberty soon um, we are very we're in the process of doing that to get it stamped where you're gated by the Um Distributions and then the packaging so that's why we're always trailing a little bit behind because we're not doing it from source We're doing it from the packages right but Still we are we try to stay close to that as possible But yes, I do challenge everyone to try to build to the the aio aio bare metal build any questions God just started the summer here then if you have something let us know But the basically we're talking about here is that this is a project that has it's been growing and we're learning from our mistakes And we're growing. I think we're getting in a better way. I said, uh It grew in such an in in enough way that even you know IBM picked it up and said, you know, this is to the point where it can be Used in production for a customer and we actually did that and so it yet there weren't you know It wasn't perfect, but it worked and it was and it's been it's been it was it was quite a good story I think especially since like I mentioned is that um a lot of folks I've seen there are forking the copax internally They want to mess with it and mess with it and and boy I I put my foot down really hard to says in IBM We are not gonna because we that was our first attempt at the first team who started at IBM that Did some of the chefs up they forked all the cookbooks and they were off in la la land Messaging changes and and I'm like well what what good is that if you haven't you know work with the community on making it better So I put a stop to that and and it worked really well because now I became core to make it better So I had to work my butt off to do it, but it was awesome So and that brings me to the growing community part right that we're always looking for feedback good or bad On the cookbooks any solutions or any questions you have we like it a challenge is always good for me And like I said, I think we have a pretty good future, uh, you know as as as yon are our new, you know Great ptl. We got going here You know, we are going to try to address the complexity issue with how the cookbooks work that shouldn't scare you away I mean complexity is the thing we see with a lot of things but I think And and I think you will see an evolution happen with how we address these things in cookbooks We're going to take a different approach to how we look at the cookbooks in terms of trying to solve a Configuration for everybody try to sign it try to make a configuration for the 80 percent of the users And then other folks can add on what they want as as they need But don't let that complexity drive the main The main branch and that's been tough because the history of these cookbooks came from a spot where they were trying To solve everything for everybody almost db2 support and then yeah, that's that's my bed. Sorry I'll take that right on the chest there. That's db2 your db2 guy. Let me know I'd like to talk to you But no db2 is not part of the issue anymore. It's magically going to disappear from this particular project And just to pair it with what mark is saying We are looking for more people to be involved Our community is agile We're the advantage of being small right now is that we have A core group of people supporting this and we we like working together and pairing and making things happen We just we would like more people to be involved and also Feedback we desperately desperately need more feedback We know we're doing we know we're building stuff. We know people are using it People just aren't telling you that it's broken or telling this is successful. We need we need any type of feedback We are on the official mailing lists. Yep. We have bug reports and I mean my job is to you know make sure that the stuff is I am the open stack chef guy, right? I am supposed to help make it forward and with yon now taking the ptl We can you know move things forward and I guarantee if you put up a patch, I'll be the first one to negative one it It's true. This guy. He's brutal That that should thrill you right because you're gonna get that feedback I'm pretty good at the giving negative ones out right away just to introduce you to the community and say great job And fix that typo and maybe I spelled it wrong. So it's all good right to get your get the bloods on He's legit a way made me Abandoned multiple patches because I just couldn't do it Sorry, I have one more question you this you said that you use it in production Right now. Uh, are you handling the hardening of the hyper visor suite the chef cookbooks? There's the system system level hardening Yeah, probably I can answer that. Um, especially for the telecom because we have also worked with great Yeah, yeah, we have also done that The telecom laboratories actually in germany especially have done a lot of cookbooks and we are using actually the official open stack cookbooks With these hardening cookbooks. So you works perfectly. You are using the hardening. Yeah, we just go from telecom. Yeah, yeah So it's basically just another layer Wrapping everything including the hardening works perfectly And the the only feedback and I know this this This sounds weird to say out loud But the only feedback I ever get about these cookbooks is well, they just work And you think we'd be proud of that, but we know we can make this stuff better And we want more feedback And it just works doesn't help us make it better Um, it works. That's great, but we need to know What we're missing. Um The container story I know is huge everyone's starting to love containers So we're starting to move in that direction. Uh, we have support for the nova docker driver, right? Um But with magnum, um, that's my my personal goal is by the time we get to austin I'll have a magnum cookbook that um, I think our community can be proud of And with that, thank you for coming appreciate your time. Have a great conference