 So for how many of you is this your last day here in Hong Kong? Everybody's going up and you're all flying out tonight Cool, we get tomorrow afternoon to go play and and look around and see a little bit of Hong Kong We haven't got out too much. So this is all good. So we're gonna get started here in a minute So come on in and sit down. I want to start really quickly and on time because For those of you who don't know me. My name is Diane Mueller I am the OpenShift Cloud evangelist for OpenShift origin at Red Hat and I'm the origin community manager and I did a presentation with this very same name in Portland six months ago and Instead of doing me talking This time because a lot has happened since we were in Portland all together. How many of you were in Portland? Okay, pretty good pretty good. How many came to my presentation? Anybody? Yes Thank you. So this time and when we were in Portland We were talking a lot about OpenShift and we did demos in the keynotes and everything and this time We're going to talk about what we've done since then with heat with Docker we have a Sam Alba in the middle and and now So long am I saying it right? So long. All right. I'll get there. Just double the O or something. So my agenda today My agenda today is to tell you to get you to understand very quickly why Paz matters on OpenStack And how you can get your Paz on on OpenStack today and Then we're gonna switch over really quickly and I have a bunch of questions that I've prepped for these guys but then I'm expecting you all to earn your beer openers and Ask some questions, too. So we'll we'll get going pretty good because there's a lot of work going on So what this presentation is really all about is cross-community collaboration. You've seen a lot of different projects come out of OpenStack You've seen Red Hat work on you've got people we've got people at Red Hat working on all sorts of different parts and pieces of OpenStack And we there's over a hundred thousand now Projects that someone at Red Hat works on there was somebody showed me a spreadsheet once it's way too tiny type to show you guys But we've really been working very hard to communicate Collaborate across all of those Communities within Red Hat and outside of that and this is really a bit of what this panel represents And so we've got a huge commitment as you know to OpenStack and I origin is our platform as a service So raise your hand Sam is from Darker. He's got the right t-shirt on Sam Alba Chris Alfonso from Red Hat Krishna and Adronado from Rackspace and the short man on the end is Clay Coleman. So We're really going to talk about how we did all this together, but to set the stage a little bit In my humble opinion and I'm going to help you try and drink the Kool-Aid today Platform as a service is a key to any cloud initiative whether it's OpenStack private public hybrid Having that platform as a service is really what's going to make your cloud initiative a success And so most of us are all here for OpenStack for good reasons And we're all still very focused on delivering that cloud infrastructure and the OpenStack community has done an awesome Awesome job delivering a wonderful open-source cloud Infrastructure and all the magic and all the pieces and the parts are there and we're all working on them together But there's something a little missing for me, and I think for a lot of developers A lot of developers we we really have come to expect with public pauses like Heroku and OpenShift online The ability to just have an idea code it test it Repeat until we get it right And sometimes launch before we get it right and then have it scale for us automatically and when we're just delivering the infrastructure and Unboxing it and when you unbox just OpenStack the deployment experience for our application is developers And there's a reason why my Twitter handle is Python DJ. I am a Python developer I expect to be able to just these days Everything's changed to be able to do that really really rapidly. I expect that self-service on-demand platform I expect to be able to really be productive almost instantaneously and get those resources without waiting at all And that's the expectation It's like you go at Christmas time and you're unboxing and the gift-wrapping that cloud that somebody has wonderfully deployed Inside of your enterprise or on some hosted private virtual cloud with OpenStack And then you get there and there's still work to do to get that application up and running And so what I like to say is that platform as a service You've all seen the layer cake is what really fills in the meat On top of that from a developer's perspective from a sys admin or in operations Getting those cloud compute resources and doing what infrastructure as a service does so well OpenStack delivers that but when I unbox OpenStack I really think that the next stage of the evolution is putting a platform as a service on it and That's the magic that OpenShift develop Delivers today. We're delivering that on OpenStack and on bare metal and on AWS and all of that It's a patchy v2 all of the source code to do that today is out there on github. So if you want to fork it Work with us collaborate on it. We would love to have you come and do that with us There's lots of flavors of OpenShift The origin project which I'm the community manager for is what upstream feeds OpenShift online and our enterprise offerings So we have lots of folks who are giving us feedback on it and it's a constant rather rapid evolution every three months This man gets to help us with a new release cycle. So we're really rapidly iterating and working with the feedback from our communities So but six months ago when I was in Portland We did a keynote demo I had anybody see the keynote from Portland when Brian Stevens stood up there and showed off a little piece of video That actually worked in a little demo. They actually worked And we took and used heat to deploy and start auto-scaling OpenShift natively on on OpenStack and That our commitment at that time was to make sure that those Templates were production ready and would be included in RDO and Ross in the upcoming releases And I'm here to tell you we delivered on that and if you go into the OpenStack heat templates You'll see two sets of heat templates one for enterprise and one for origin and a lot of that is due to Krishna and Chris Here's work that's been being done so then that was six months ago and then six months in that six months time a lot of a lot has happened and Docker came along and we started Collaborating we're really proud to be part of the Docker Project and working on that we have people inside not just working on making sure that OpenShift works with Docker and Will support Docker, but also contributing to the Docker project itself And so we're really happy to be part of all of that and Then the solemn Solemn or whatever you want to call it project happened and when did you start that Adrian like two three weeks four or five weeks? We we started about October 1st was our first public meeting. Yeah, we announced The project to the OpenStack developer community about two weeks ago. Alright, so this is really fresh And so we wanted to talk today a little bit about how all of that works together So we're really excited about that so enough about OpenShift and Paz or anything what I I've got a couple of questions I'm want to talk a little bit because I what I see it is happening is we've done the heat work All right, and Krishna and Chris and Clayton on the end a little bit, too For Chris the question I had for you is you know What what made Red Hat decide to start doing these heat templates and why and why was it important? So it actually makes good sense to use OpenStack and get heat everything on there Getting a basic OpenShift set up online involves a lot of different pieces that need to be integrated with each other And heat provides the perfect orchestration layer to be able to do that. So with heat you can spin up the all of the support services like the DNS Mongo for data storage and such as well as the nodes that provide the API front-end and Run all of the containers that are part of the OpenShift service. So that was a perfect fit and that's how we went So and but that does that mean the puppet the chef scripts all go away they don't actually so when we are spinning up the nodes using heat heat in turn will trigger the puppet scripts are answerable and There there are also shell scripts to do all of this So you can choose which one you want and heat will trigger those scripts to be able to set up So a quick question for Chris then One of the things Chris has been work Chris Alfonzo has been working on is making it work with enterprise and the enterprise strips But I'm wondering because I know you've had to run some into some limitations and some of the reasons why You know the limitations deploy in a pause with heat what was what were some of the issues you hit? I wouldn't really call Them limitations I would say that there's definitely some homework to do ahead of time We we are in the midst of a lot of design iterations in OpenStack For instance going from Nova networking to neutron networking There are different resource mappings You can do you can specify in template native Neutron mappings rather than AWS based I Guess resource mapped to Nova networking and you know We are in the midst of a lot of change. So there's some some maintenance and some homework to do along the way and One of the other things that we discussed earlier this week was that You really have to consider What the end result of your infrastructure is going to be in that if you want elasticity and quick elasticity you have the burden of Maintaining your images such that when they come online They come online very quickly with all the security Arata already updated and can as much configuration done as possible ahead of time such that they The time to to going live is is very short. So but that's really not Heat related and it's not really I Would just say that heat provides a great orchestration layer to to Carry out some of those maintenance items, but heat is is not enough Then the next the next phase of what we're doing with Solomon is Hope Solomon. I did say Solomon. I knew I was going to say Solomon. So long Really will take us into that the next generation of So There's a lot of moving pieces and if you look at the design diagram if you've caught any of Adrian's discussions earlier this week He'd still a fundamental orchestration component in that stack and and so It's making rapid progress if you've gone to any of the heat sessions or design sessions Packed house. It's it's something that a lot of people are consuming and very interested in the progress of So when we combine the heat with the next gentleman down that the thing Sam Then we've we take to the next part of our conversation is bringing Docker online into this this universe of open shift And can you tell us one of the questions that I've been getting asked is what's the difference? Between a VM and Docker and what's the value out of using dockers as containers? I mean that would be a good way to get into that. Yeah, so what I would say is that containers are basically more lightweight than VMs and portable so for instance, you can deploy hundreds of containers really quickly on the machine in like a few milliseconds and Portable in the sense that whether you go for provisioning on bare metal or on a VM Docker make sure that you will deploy your containers or always in the same way So, yeah, and also containers are easy to distribute with Docker We have something called the Docker registry and so we have a containers format And so your containers are always the same and and thanks to the registry. They are easy to to deploy anywhere There's another fundamental difference to the way the containers were to the way that VMs work in a VM your app preallocating a set of memory and other resources in order to run an environment you get an entire operating system with a container you're getting a Slice of the kernel and your memory utilization is only what that individual process or group of processes within the container is consuming So your total utilization of a machine can be much better with a grouping of containers than it can be with a grouping of virtual machines So it's a way to get a better usage or better utility out of a set of equipment So that brings me to asking you a question to maybe in a nutshell trying to describe how solemn is going to work Tell us tell us in your words and and and why you're so so enthusiastic about it Not everybody here has been to all of the Unconferences and everything that we've been to so maybe give a quick Okay, Solom is a new project It's a little bit special because it's one of the first open stack I think it is the first open stack related project that has ever started with zero lines of code And let me explain let me you're all laughing because you think that's funny But it's not funny. It's it's actually the one thing that makes this project really really interesting Because it normally when you have an open source project Somebody has made all of the important decisions already and you get to this point where it's at its MVP status It's actually doing something. It's working. It's almost finished when it gets announced And there really isn't an opportunity to change very much When you come out with just an idea and you say look these are some gaps that we see that Are in our our ecosystem that we care about and we need to get better in these areas And we want to focus on these areas We have this plan for what we want to build but we want to get input from all the subject matter experts and Build the best possible when we can and almost everybody who's involved in this project If you go to Solom.io the website the community website You'll see the logos of the people who are who are involved in this about that. That's about to double since we've You know started talking about this more openly with the wider audience Every single one of these companies had built some kind of platform as a service solution in the past or some kind of a deployment solution in the past or some kind of a Is it you know container technology? Companies so they all have something that they're bringing that's valuable And so what we're going to end up with what we're done when we're done is something way better Then if any one of us would have built something in isolation and then common said Here's this wonderful magical solution. It's going to solve all your problems so That's a great description of all the people coming together to that But can you describe a little bit more what the the vision and goal is that you've set out for for Solom so there's a few there's a few key focuses the first is how do you in the world where? Agile development is becoming more and more popular and People are learning more and more how to do this kind of iterative development and at the same time We've got this trend of you know an insatiable desire for cloud technology How do you get those worlds to work together? How do you make it really easy for somebody to develop software and get that software from source code all the way to built and running on the Cloud and how do you make that super low friction and how do you have tools that make it so that people loved to Love to write code on an open stack versus some other clouded ecosystem Another area is an area of application portability So if you have an application That runs on your private cloud and you want to run that application on the public cloud There should be a way to easily forklift that and move it today past solutions are generally biased to one or another Of these worlds they're either focused primarily on private cloud or the focus primarily on hosted in a public cloud environment And there's not a great story about an equivalency Between them so one of Solom's focuses is Getting this equivalency between a public and private cloud scenario and making a real story so you can actually get things that work And both equally well So where is the the line between heat and Solom so so heat is primarily about orchestration It's about getting the resources in the cloud set up in accordance with a model that you built Solom is about taking source code Putting it through a CI and CD process Giving you the ability to do things like Get your code built reviewed staged tested gated To the point where you generate a heat template and then you start doing your continuous deployment things Which are feeding it into the into the actual cloud and getting it set up on the cloud Monitoring it scaling it healing it when it breaks those sorts of things So there's a whole there's a whole set of things that happen before you even generate a heat template that Solom is concerned about It's also concerned about things like when you deploy initially You're probably going to deploy after you've gated all your testing you want to deploy into a Into a test environment or a staging environment before you go production with your app And it needs to be super easy to go from production Status from test status to production status and you need to have something that's going to help you kind of walk Through those stages and make that super easy for you to do So that brings me to the next one where is the line Clayton perhaps you can just to do this part of it The line between OpenShift and Solom so when we Think about what OpenShift does today OpenShift is totally focused on the developer experience making easy for a developer to Build and deploy applications and run those in a number of ways But one of the things that we've done, which was a deliberate choice was to try and limit The variables to make it so that the fundamentals worked easily and you had a flow and what we found over time With the evolution of Docker and as OpenStack has grown. So, you know when we started OpenShift just over Two and a half years ago now almost three OpenStack was really in its infancy was growing. There's a number of the smaller projects and as OpenStack has matured and Docker has come along and really demonstrated How you can build a really compelling experience around Taking a set of software a process an application and bundling it in a way that's easily portable And works across any Linux any Linux kernel. You really have these two almost intersecting forces that allow you to say With OpenShift we want to keep evolving. We want to expose more capabilities We want to build a better platform as a service And so as we look through all the things that we wanted to build we realize The kinds of capabilities we want and the kinds of features that we want to expose to end users are the exact time exact same sort of capabilities that exist in OpenStack to build upon the stack to give you know, everyone not just the developer But the IT administrator and the organization itself the ability to put together and to run the application life cycle And the entire IT infrastructure and so when project Solem came around When we started looking at it it matched almost exactly the things that we wanted to see out of the next evolution of OpenShift So we're incredibly excited to be part of this because you know again as Adrienne says It allows us to offload a lot of the things that have already been solved Or are solved better than they had ever been in the past because a bunch of different people are coming together and trying to Find the right solution in an open way Cool. Thanks. So one of the other questions that we have a question here. Cool. So maybe so maybe we could get Clayton Okay Let me paraphrase that as Too hard throw that back to that man for asking the purpose that question is why not just use OpenShift? Why do you need something new? Is that is that your question? So but maybe I don't understand. I don't understand what you're referring to as brokering. Can you explain that? So Adrienne, why don't we let Chris try and because at least let me hit on Part of that question because I think it's two or three parts there. Number one is the the goal That heat has is to be an infrastructure Orchestrator it is it is not get in the business of the entire life cycle from riding code to building code to testing code putting it through the entire process before To include getting to production and through environments that is not what heats going to do So that's that's that was the first question that you asked now now we look at well What is the platform as a service? Additive and the differential between OpenShift and the idea of Solom OpenShift is a rel and derivative based solution We use completely different well we use Technologies such as se linux Pam namespaces We use a concept of We call them gears their directories with permissions around them to and we use C groups to isolate processes, etc That's not portable That doesn't that doesn't give us the ability to No, no, so so what we're looking at now is a technical pivot right so the the idea of of Managing picking a new technology to replace Isolation and multi-tenancy and and something on that has parity with a lightweight concept of a directory or a gear That being a container and how you manage that and and how you fit that into an entire pass life cycle or an Application life cycle management. That is the technical pivot point. So you can't just say well, I'm going to rip and replace Oh, the OpenShift has with the existing open-stack projects because there's still a lot of work to do and that that Block of work is what Solom intends to put together That was just one example of a slice of the technology so I think you know and Chris pointed this out is Containerization has evolved a ton in the last three years And so one of the things we've been doing internally was starting to evaluate the next steps about where containers are going, you know You know on the rail team, you know, some of the guys who are doing se linux and contributing to live vert LXC And there's a lot of internal iteration. I said, you know, there's a there's an opportunity here with Docker to join with the things that Docker brings on top which is you know incremental addition and Some of the the packaging aspects around containers that's better than what we have today And so, you know to us it's a natural migration on that aspect and then you know up hands over to Adrian but all of the capabilities that are important to an IT administrator the developer wants one view of the world and Many IT administrators want to remove or certainly limit the kinds of choices developers have to make both for you know Operational concerns organizational concerns. And so we want to expose more capabilities to the IT administrator and open stack is the right place To expose IT administration Containerization So basically the technologies that we used to create the open shift gear where we had see groups and namespacing on all of those Those have already been pushed into the kernel and they are called kernel namespaces under Linux Docker is all is basically using those technologies and it's adding another layer on top to make it very easy to create redistributable redistributable images you know packaging Which makes it very easy for say a software developer a mysql person to create a little mysql Package that can be distributed to other passes and they can run easily over there So the the namespacing and all of that is already in the kernel. This is basically a way of packaging and And in in solemn we are using docker's technology used using that packaging to make it easy to migrate this Well, we call them cartridges in solemn To migrate those so what there's another question down in front here So I think there's an evolution here that will happen You know open stacks certainly can support Windows VMs running on hypervisors containers are a concept that's specific to Linux today There are some work going on on the communities to do the same kinds of things as containers Maybe without the same kernel level integration, but I think and I'll you know hand this over to Adrienne I think that there's I think the important thing the stuff that the solemn brings is because it's dependent on heat It offers a lot more flexibility in how it can deal with the kinds of things that it opens that guard of supports So you don't have to use container technology It's compelling Because it's more effective to run your infrastructure on containers. It's faster to turn them on It's easier to move them around the images are smaller. They can be layered There's all kinds of technical reasons why Containers are interesting, but you wouldn't necessarily have to use a container if you were interested in running You know a platform of operating system platform that doesn't offer the feature so if what you really want to do is build in net and Deploy through a cloud and have it turn on virtual machines that run Microsoft operating system and Microsoft Application stacks that's absolutely possible But you still you still need all the features about having an API that allows you to extract your cloud To be able to represent your application to be able to export and import between public and private clouds All of that stuff still applies the same way Solom doesn't care about operating system Containers are an operating system feature offered by Linux today, but these things are our separate issues When we talk about what we want Solom to be we want it to be the big 10 So, you know a lot of paths operators and implementations up to this point have chosen things that allow them to deliver Specific types of options. I think reading part of what makes open stack You know amazing is the vendor neutrality right the idea that Where necessary you solve a problem in a way that lets everybody participate and so continuous integration flows that are based around Windows I don't see any reason why The Solom project could not Have people contributing who believe very strongly in those sorts of solutions like and this is you know When Adrian says there's no lines of code part of the goal is to kind of gather a lot of people who have a lot of experience and a lot of different ways With application life cycle management paths and to come together and bring you know build out the kind of the core things that we all believe in source code continuous integration continuous deployment Reusing the infrastructure and giving IT administrators those pieces to work with so I think I saw another question to Keep talking about It's a it's a it's a it's a development collaboration. It is a project. It is not a software distribution of software It is in its designation is called open stack related An open stack related project is when an open stack team gets together to work on something together Where they have not yet filed for incubation so we're to file for incubation. You need to have something to submit Yeah, I think the thing that we have to be careful with the language that we use when we describe Where we're at and what stage we're at in the project and we are working we're getting together in a couple of weeks to work further on a blueprint to move this forward to be a You know if we get consensus among the group a blueprint to submit with some code base to become a valid open stack Project, I think that's the course of action. We're working. We're not there yet, and that's the point I think Rob's trying to make well So I think when we say I think there might be a little bit of confusion when we say what we want to support You know the idea is to build something that's open stack first You can't build something open stack first by Taking a bunch of images and running it on open stack like that's not open stack right open stack is a process. It's a community it's It's a contract between the companies and the developers in the open source community and so You know when we think about you know open shift is almost separate from this When we think about what we want stolen to be I as an open shift developer I want to help build the best possible experience for end-users Developers IT administrators that takes advantage of everything and open second You can't take advantage of everything and open stack by retrofitting I mean I really firmly believe and I think this is why we responded so strongly this we really believe that You know there's a there's a layer on top That's the experience when you talk about fundamentals and how something works if you're not building on heat Why are you an open stack if you're not using Nova? Why are you an open stack if you're not using key stoning glance and these things give what? Yeah, but there I think the point that that Clayton is trying to make is that to use the resources natively to open stack as part and parcel of the project But as but as the technologies evolve and as open stack has evolved We So this time how we're going about it is collaboratively We're designing with other platform as a service vendors other cloud hosting providers other people interested in this space So as opposed to doing it as just the open shift community We're bringing in a whole lot of other people and collaborating and that's part of why we're here today with with all these There's it another question here. You have a question Kind of So this is the subject of high availability is something heat is already very It has in its roadmap The ability to do multi-region deployments There are open blueprints for this as soon as open stack offers the ability to do this and he surfaces those capabilities You need features and know if I you need features and he features in order to do that once those are surfaced so There was another question question right here Well, yeah, so this has more to do with newly developed applications So this is about how do you make an application a newly developed application somebody that is building from source code? The ability to get their source code into fully built running on the cloud status It's not about packaging up existing applications necessarily I mean you could package an application in a container image submit it to the soul of API It would generate a heat template the heat Orchestration system would deploy resources those resources would get the bits and you would have your deployed application Another option would be you bundle up your application into a heat template and You deploy that directly to heat and you bypass us completely It's definitely not out of the realm of possibility though for legacy application build deployment and associated infrastructure anything that At the OS level that your application is going to run on but it's still a fundamental it at the end of the day is the runtime environment The the Solom project or even an open ship today You know that that's the framework, but at the end of the day the runtime environment whatever whatever supported and packaged There's an interesting, you know crossover here is that to take advantage of some of the things that cloud offer to take advantage of high Availability, you know there's certain ways that you have to build your application You don't just get it for free and so with legacy applications. There's really probably two types There's the type where you know, there's things that are isolated in such a way that as Chris was saying they can run You know you can take in via C++ application that listens on a network port You can probably bundle that up into a Docker image, right? That's something you can do today and then Solom is really about Giving you the flow into that process and as Adrian said linking it together So there's a number of options. It really just depends on what kind of application you have there Maybe legacy applications that could very easily be converted and there's some that may not be Then answer your question This is something you know at red hat we believe pretty strongly and so when we talk about open ship We talk about the long tail of it computing right there's a everyone has hundreds and thousands of it applications that run in their infrastructure and I think that over time what we want to evolve and you know This is something we we do to some degree in open shift And this is something that Solom will eventually take up in various forms is Patterns and mechanisms by which there's best practices and flows that allow people to convert it You know the the focus today for Solom right is to build a kernel that you can build an ecosystem around and to get those Pieces in place the pieces that you know everybody in the community can agree on And you're the best practices that people have come to the ability to use Docker the abilities open stack natively It'll take some time to get to that next stage for Solom where you can take legacy applications People will be out there vendors will be out there that make it easy to make that transition There's another question out here Go ahead And It's open stack related because there aren't there isn't something to submit for incubation I'm always in the very clear about this if the community wants Solom to be incubated It can ask for it to be incubated and it will become incubated But it's about right now. It's about making it work Let me answer it this way Just mentioned that I know that you're with HP so the active-state staccato group is actually working and participating in this So just so you know there there are other folks out there Who see the value in having a common API and a way a common way for everyone to use these building blocks for pause or pause? Functionality and that's more of how I see Solom rolling out. It's not an either or choice. Yeah Red hat as red hat as a past provider active-state as a past provider Cloudify is working with us logic is a past provider I mean many of the of the participants in Solom are past providers and are using open stack as downstream I guess I would almost ask, you know, what's the concern right? Is it the concern that it takes? Focus and attention away from the open stack community and I think that you know That's one of the benefits of the open stack community, right? There's a bunch of people who often have different competing interests working together, right? So I don't think Solom should steal time and attention away from core developers I think it really comes down to you know, what is it that the developers and the companies that are working with open stack believe it? You know, do they find value in coming together and leveraging the platform more fully it? You know people can go deploy open shift or cloud foundry on top of open stack today and To us it seems pretty clear that there's a very natural evolution in the past space to have this I think of it like, you know, I think of it as this This set of levels so you talk about like the OSI network stack You got level seven all the way up here Which is your applications and you got a bunch of wires down here And I think that's what open stack represents is open stack today has gone one through three or five But at the end of the day, you know, everybody in IT organizations trying to get Applications deployed or they're trying to run the software like open stack is there today to run software And over time it's just going to become more natural for people to want to build better software on top of open stack Because if you hide all those details You end up not being able to take advantage of that Has I'm going to let the gentleman behind you ask a question Hopefully not because I can't pronounce it. So, yeah When we think about this from a technical perspective, right? So all of the things that we want to do all the capabilities that we want to enable an open shift are things that open stacks are doing I don't want to go rewrite that like I don't want to bring Federation I don't want to write Federation. I want to use Keystone and There's kind of a you know the things that we believe that we do the best is the developer experience and packaging and distributing software and so we want to help Bring those aspects of what we're familiar with to the solemn project And we would like to use solemn and become more deeply integrated with open stack over time. That's a transitional thing, you know, obviously, you know With no lines of code, you know, it's kind of hard to say well, we're gonna switch over tomorrow But in the long run we want to be you know have something that works just as well as open shift does today for all scenarios And then offers all these new capabilities to users and then user I think that that's the same way that many of the other vendors who are involved feel you know the customers and And the people who are involved in the project they want to see capabilities that kind of span stack So we want to give it to them. Cool. So we've got time for one more question the general in the orange Yes Yes That was a good short answer There I guess that now we have more time for there was one more question over there at this gentlemen of the glasses and it doesn't matter It can be in a virtual machine or it can be on bare metal. It depends on what the cloud operator refers Christian, did you want? There was a there's a really interesting discussion that's going to go on You know how do containers fit in Nova some of the design sessions today talked about that It's just you know everybody you know containers are something that's new and there's no right answers But like a VM is not a container and there's a lot of you know legacy there But from an application perspective A VM something that's a compute resource is a place to deploy or run something and I think we want to be flexible To those options Clayton accidentally said that containers are new which isn't What he meant is that There's been a resistance to using containers because they've lacked certain isolation and certain namespaces. They haven't They haven't really started to see a lot of traction until now I would ask a question to Sam Why do you think there's such an interest in docker now and why is container technology taking off where it hasn't in the last Five years. Yeah, so actually that's interesting because we we have been running containers on production on the past at that Cloud for three years and we were basically supporting thousands of application on prod and so docker is actually the result of that we made a lot of mistakes and By seeing docker on so long right now It's it's I think it's a great thing because it brings a major approach of running containers directly for free from the beginning of the project and I think containers are taking off right now because it's easier to To run them mean by the time we were running containers on on that cloud we Were relying on on kernel patches and asking people to patch their kernel to use docker is really painful So it's not the case anymore So yeah, basically there are there are easier to easy there are more easy to use now I have to apologize for saying new but it's the idea I think of the container as something that can stand on its own that people are running in production and people who learn from the mistakes That's a you know a natural part of every software process, you know and for the For red hats, you know the the folks we have on the kernel team who are working on this We've been working on this for years, you know kind of taking these final sets of steps That allow us to work with docker and to put some of these pieces together Like live vert or live vert LXC and liver drivers and SE Linux Even app armor, you know all of these things are capabilities that are coming together in a way that give application developers Something they probably never had in such an easy to use package with docker before which is the ability to take a process and a user space And run that anywhere miss. That's huge, right? You can't you can't do that today and docker is made docker's really made that process as simple as possible And I think that's really the shift that I see Also, something I like to add is that right now docker has has an ecosystem. It's basically 200 of contributors thousands of applications on our public registry and By having docker in open stack and in solemn. We are also bringing this ecosystem with us So yeah, I think so I'm can basically take the advantage of that So I think we need to wrap up a little bit, but this has really been What we're seeing is this whole evolution and six months ago We were in Portland and we were just talking about heat. We're barely talking about docker and now The next conference is in Atlanta and six months from now We have a lot that we've committed to we're talking about so it's going to be very interesting to have this same Session in six months I'm not committing anything solemn But at least, you know some they're there to solemn I think by the time that six months comes around and can Adrian can you tell the dates of the the next solemn session in Space to face a meeting Happening in San Francisco November 19th and 20th. So if you are interested and want to be part of this development Collaboration you're welcome to attend Look on the open stack Developer mailing list for the link to the invitation and it'll also be on solemn.io and there's a few other When is it? Where it's in San Francisco at the rack space office downtown 620 Folsom Yeah, so there's a couple of if you go to solemn.io you'll the date will be up there eventually when it's firmer This is where you can get in all information on all of these things They're out there the heat templates that we talked about earlier that are in productions are on in github under option stack under heat Templates you can grab them there What we're really looking forward to is getting all of you to collaborate with us on whatever it is this next generation of Platform as a service features functionality is on open stack and helping us Collaborate and design the next step. So thank you very much and thank you very much to the speakers