 All right, it's 12.30 now. I'll give everybody another minute or two. There is chat turned on for there. So if you'd like to ask a question, you can always ask it in chat. Turned off, kept everybody on mute so that we can get a good recording of this for other folks who can't join because there's a lot of people who are time zone challenged in the commons group. So I'd like to get started. My name is Diane Neuer. I'm the community manager for OpenShift and I'm really pleased to have this many members of the OpenShift commons groups joining in with us today. And there's a number of you, already 20 individuals here. So I'm really pleased with that. This is the first in our series. We're gonna do about one a week for the next little while on different topics around OpenShift and V3 ops, OpenShift on OpenStack. And this first one, we have the great pleasure of having Mike Barrett who's the product manager for OpenShift from Red Hat. And he's gonna give us an update on OpenShift V3, the new stuff, and sort of set the ground for what OpenShift commons is. And so I'm gonna let you get started there, Mike. And we'll save time at the end for Q&A. And as I said, please use the chat room for questions and we'll get started then. All right, thanks all. All right, thanks Diane. So Diane mentioned my name is Mike Barrett. I'm a product manager on the OpenShift team. I specialize in the on-premise distribution or the private cloud distribution. And so I get to go out to a lot of our customers and talk to them about how they're using the product, how they're integrating with their data center infrastructure, how they're working with developers, applications and all that fun stuff. So thank you for having me. We're really happy and pleased with the comments, right? It's a very specific implementation of a community gathering. So let's get into what that is. No barriers to entry, right? You don't have to buy into this group. What we try to do is bring in an assortment of different people from different backgrounds, our actual customers, our ISV partners, our VAR resellers, our code contributors up in origin. You're all invited to this gathering and you all have an equal voice. And what we're trying to do is just structure around what that voice can be. We'll suggest topics to get things started. We'll hope that you guys will start interjecting with each other, explaining how things are going. So that's really the premise of the comments. So really bring our larger community together. It's a meeting place, right? It's a dynamic website and it's more than anything else an information repository. It's another place to get more information about what we're doing with the product, what people are doing with the product more importantly. So we have a lot of customers at this point in the community. This is a way for you guys to start talking to each other from a peer point of view, to share your interests and goals. Again, tell you how many times I've been in customer meetings where I wish another customer was there and many of our customers want that opportunity to reach out to each other without us in the middle. So it really is the next step for the product. Once you have this many customers, it's just a natural progression and we're ready to take that further with you. You don't have to be a code contributor to be part of this community, right? We can better the documentation. I can get feedback from user stories. We can talk about the UI design. We can talk about the coloring. We can talk about pool requests. We can talk about just about anything you want to talk about how you've implemented the product at your own data center. How you've mitigated DNS or DMZs or did global routing or found a solution for shared storage or integrated with a continuous integration tool set or got into a larger get deployment. These are all things you can start sharing with each other and with the community. Participation, lots of different places to get involved. For most, it's an email alias, right? So OpenShift-commons has been active now. If you haven't sent an email out there to OpenShift-commons, please do. Introduce yourself to the other members that have signed in and said that they wanted to be part of this community. It's an ice breaker. Just give a little bit about yourself and why you joined. Other than that, we are on all the classic multi social media conduits, right? The more important ones for this community, I think we're going to be the Trello boards. If you have not looked at the OpenShift Trello boards yet, totally do. There's a lot of information there about where we're headed and a lot of information where you can contribute back to that open source project. All of our developers are on IRC. So that's another great area to grab on to. Diane runs our Google Plus community. I think we're over a thousand members at this point. So that's another one to join. Facebook isn't as attractive for, I would say this community. Blogs are definitely, and in fact, if you ever write a blog on the product, just ping us or the community and we'll point some social media in your direction. The SIGs or the interest groups are going to be important. We have two interest groups right now. We have Platform as a administrator, somebody who owns the Paz, keeps it up and healthy, deals with a lot of the day-to-day operations. A lot of those topics are very specific. So we have an interest group on that side. And then the next one is where we're going with the version three product, which I'm here to talk to you about today and not some bolts and designs and all that fun stuff. These briefings, which this is an example of, are gonna be on BlueJeans. So that's where you're gonna be able to hit us up just like you did today and find out more information about the coming topics. So let's talk about the next generation. This is a product that is under active development right now. It's OpenShift version three. We're asking our developers to maintain two code chains right now. They work on the 2.x and the 3.x. We don't wanna stop cold turkey on 2.x. We're still putting features into that and we'll continue to do so. That end-of-life support date is well into 2016. So we understand it's gonna take a while for our larger customers to migrate over to 3.x. When we look at 3.x, it's got a lot of great components that I'm gonna get deep into. But first, why make the move? And it starts around innovation acceleration. We really live in a world where applications have a shorter life cycle with the market capitalization. We look at the World Series apps that hit your iPhone and Android. A lot of people made a lot of money off of them and how many of them are making money off of them right now. So it's a smaller window to get in and get out. It's also a more innovative, more cycles during innovation, right? We're not just doing paper processes and doing simple CRM relationships with our customers. We're doing larger analytics. We're doing hit and misses and we're really mapping the next generation application. So we need a platform that's gonna allow us to really innovate, spend a lot of cycles, but not be forced to eat that cost. Be forced to stand up that infrastructure. And we find that platform as a service really balances these two approaches and how do they balance it? Well, we're using containers. We're moving to microservices and APIs for those services and we're moving to a DevOps relationship. So where are we innovating? What is new about this platform? So right off the bat, it's based on REL7. We're moving away from REL6 and onto the REL7 with this platform. REL7's got a lot of namespaces that we require to pull this off. We also have, Atomic has a new distribution of REL7 that I'll talk about on the next slide. If you're stuck on REL6, we can totally run REL6 workloads. We just run them on top of a REL7 host, which run them in the guest container. So no problem there. Container model changes drastically. We move over to a Docker model from our gear model. This allows us to pick up more namespaces like the PID and the network. Also do some more real IP work and other features. Orchestration changes, right? We move from our Ruby broker with a active MQ message bus and a Mongo storage over to a Kubernetes backend. And I'll talk a lot more about that. Packaging model changes. We're no longer adding personality or content into the gears with cartridges. Kind of merge the cartridge with the gear and we come together under a Docker image. Platform routing. Right now in the 2.x, we pretty much give every application its own routing. We see an HAProxy in front of it. You integrate that with your larger data center fabric. We're moving to a larger central fabric and I'll talk about that. So Atomic, right? How many pads providers also have an operating system? And right down the hall from me, we have the rail kernel engineers working night and day on this atomic distribution. It's just enough OS. It's moving from 4,000 RPMs down to 400 RPMs. Its purpose in life is to run Docker containers. So it uses a RPM OS tree update mechanism to give you a more confined environment and adding software to it and rolling back off of different file system partitions. It allows automatic usage of system D to init and watchdog the containers that you may run on top of it. It automatically brings in SELenix policies for us. So a lot of the stuff that we were doing in OpenShift, we now push down to a dedicated operating system that's built solely to run containers. And this really breaks down the operation costs that we were facing in the previous product. Current generation, you guys seen this slide a lot, right? It talks about our gears or SELenix policies. We sit on top of nodes, use our broker. That changes, right? That is what we're here to talk about today, these nuts and bolts. So on the broker layer, that becomes a Kubernetes master. And on that Kubernetes master, we have some services that are important to us. We still will support the Apache mod and all that authentication that you'll find there. We're adding to that OAuth. We've had a lot of requests over the last couple of months to add OAuth to our authentication. So that's gonna be there for you. ATD is our persistent storage layer that keeps track of the services across the cluster. It's found in a lot of solutions like this. So it's got a really good track record for the job we're asking it to perform. I'll talk a little bit about that a little bit later. The replication controller, this is another nice thing about Kubernetes. In order to get onto the platform, you have to have a health definition. And if you fail that health definition, well, I'm just gonna just replicate you somewhere else across that Kubernetes cluster. I'm gonna bring you up. So no longer does it matter, you have different recovery processes if you've lost a node, if you've lost a container, if you've lost a routing mechanism, doesn't matter. We're just gonna replicate you on another part of that cluster. The scheduler is really the placement policy, right? This is how we find the least loaded node. This is how we identify which nodes have the right content, how we identify which ones are in the right availability zones or the regions. What's nice about Kubernetes though is that this is very pluggable and there's other vendors in the market that are interested in contributing to it. So we have Hortonworks talking about plugging in yarn, we have Mesosphere talking about plugging in mesos. So that really allows the platform to grow organically in that ecosystem. Moving out of the broker over to the nodes, these are also called Minions and Kubernetes speak. We have a couple of nice things to talk about here. We have pods. Pods, it's an interesting name pod because it makes you think that there's a lot of things inside the pod, but it's not the case. So a pod will typically wrap around a single Docker container. You will have pods that have more than one Docker container in it when you want low latency or you traditionally would run things on the same box like a Postgres and it's admin daemon or something like that. But for the most part in the applications that we end up deploying and talking about, you'll have one Docker container in a pod. For an application, you'll have multiple pods spanning multiple nodes. You can run more than one pod on a node. What's really clever about the pod design though is that it holds the definition for the shared storage and the network for that Docker container. This allows a little more mobility for that Docker container as it tries to find another host across the node should something happen. But that abstraction layer really opens the door to a lot more use cases for us. On top of the pod, on every single node out there, there's a service layer. And the service layer is what talks to SED. It's what knows the relationship between pods, the form applications. It's what knows what all the nodes are doing. In this way, every node what knows what every other node is doing. So it's very easy for us to replicate and to move things around if everybody knows what everybody's doing. And the brain trust of that relationship is that SED. We have one routing layer, right? You don't see a HA proxy standing up in front of every application anymore. You'll have one. It'll be for the platform. It'll be customizable. It'll be HA, you'll be able to integrate it with your own data center fabric. But we've had a lot of requests to move to a central routing layer. The developer experience changes, right? We wanna keep the developer experience that we have today. The developer shouldn't have to know anything about Docker just like you didn't have to know anything about gears. He can come in at a code point of view from his IDE, from his Git, commits, whatever the case may be. That stays the same. We stand behind that 100%. What we needed to do is add something to it, right? We now have these developers that wanna bring Docker images from their laptop or from Docker Hub or from other locations into the platform. So we had to do something to allow that, to allow that pool from a local repos, that checking, that managing, that bringing up pods and all that fun stuff based on a Docker image that you're bringing into the platform. So I'll talk a little bit more about how that happens. Applications are still deployed, REST APIs are still there. So that's pretty much the holistic picture where we're moving with the platform. What we think this represents is how was we, our first move was the Docker. When we looked at our, this is going back probably two years. When we were in rail six, we're working with the rail kernel engineers. They're coming out with their own next generation container, putting a lot of those namespaces and a lot of those attributes into rail seven. And Docker's coming up at the same time. And what was attracting to us was the larger community that was being born around Docker. We have the kernel engineers that are capable of writing container technologies. What it didn't have was that ecosystem, that outside of us ecosystem that we wanted to take advantage of. We saw the same exact thing happening at the orchestration level. Shortly after we made the decision to move to Docker. And by doing it at both levels, by commoditizing the technologies at both levels, we pick up exponentially larger communities than ourselves. And this has been just an enormous win for the platform. Because what we have always been interested in was the developer user experience, was the services, the deployment patterns, the things that we offer, the integration with Git and Jenkins, and really the superior nature of that rail operating system and allowing us to consolidate a lot more workloads onto it. That's what we've been about. And this is the next generation pass back we firmly believe. And this is where the industry is going to move. What an ecosystem it is. Talked about that choice to move through it before. A lot of vendors from the competitive point of view, from friends and alliances, from different industries altogether. So they seem to all be coming together around one solution. What is better, right? What is better in this architecture that I just showed you? You know, OpenShift has been a bit unique in the Paz market in that it allows for non-HCP traffic. We just released our XPaz, our Fuse cartridges two months ago. They allow non-HCP traffic to be born and routed to and from the platform, typically in a Paz market, you use HTTPS on the platform and you call outbound to services that you need and you bring them back in. The difficulty was routing back in. Routing an outbound was quite easy. Getting back to the same gear or the same container was difficult for them. We're using an SNI trick to achieve it in this current platform, the 2.x platform. But in the 3.0 platform, that goes away. A lot of that heroics that we were doing at the node level with the Apache routing, with the V-hosts and then with the loopback interfaces, you know, 127.0.0, that all goes away as we achieve the network namespace. So we don't have to start with the HTTP. We can start with the database. We can start with non-HCP traffic and we can build from there. So it's a different beginning point for applications. The other thing that Docker brings to us is this immutable concept. Operations can start from that gold image and then anything that changes, such as code pushes or new features, we can cause a triggering or a layering to occur. And then we can use that layer instead of changing that gold image. So we have that immutable standard. You can further decouple depth from ops, right? We can go with known deployment patterns. We can learn from our 2.x with those hundreds and hundreds of quick starts and cartridges that we have out there and how over 2 million apps deployed on openshipped.com are many enterprise customers. We know how to stand up a lot of these applications. That deployment pattern just wasn't there in say the Kubernetes or Docker and we're bringing that to it. You know, better abstractions of the network, storage and health. Network has been probably the number one integration point that we spend the most time with our customers. And so this gets a lot cleaner as we move to a Kubernetes cluster with the pod model. The shared storage in the 2.x version were blocked on block storage and API based storage like S3 or ESB. We pick up the ability to do more file based storage which is very helpful because a lot of customers are using that because it's typically cheaper. And health, right? We're talking about that replication controller before and being able to replicate without doing very specific things for very specific failures. It moved to a true cluster, right? This thing looks more like an HPC type cluster that we saw in the early 2000s and where we're able to move things across farms across larger segments of boxes. You're allowed to declare how you want your application to look, what qualities you want from it and the cluster will make sure that's maintained and make sure that that's out there where you wanna be introspective if you will, you'll do that the scheduler layer. So what does OpenShift bringing on top of all this, it gets confusing when you start commoditizing your components, what features were just in Docker which features were just in Kubernetes which features are just in OpenShift. And what OpenShift's focus is on is that Docker linking, right? Being able to do that overlay network across your multiple nodes and being able to cluster out the EAP instances, adding nodes to Tomcat, scaling your databases, adding sharded MongoDB instances. This is what the world that we live in. This is where we wanna be and we're able to bring that to that Docker linking projects. Around the user experience, right? We're more interested in the developer projects. We're more interested in seeing a project be born with team members, with team members being in different roles, with seeing usage of resources or IP and other things. That's what we wanna track from the developer point of view of a code project. And it doesn't necessarily need to be a developer, it could be a service admin or operations admin that owns that project and delegates out. The next one is the big one, right? This is, if you looked at our existing user model in 2.x, our workflow, it's very source code based and binary deployment based. It's adding contents to applications, adding new features to applications. And to do that, we needed to bring that over in an open source project called a source to image that I'll talk about in a little bit. But that allows us to give a developer a Git workspace or an IDE workspace, have them commit back and have just magic happen, right? Have Docker layers be born on the right atomic node, on the right shared storage, on the right pods and bringing those up with the right routing. So that's a lot of heavy lifting that we're doing for that developer. Deployment patterns, we already talked about moving things across the life cycle is important as well, right? We wanna be able to promote code from different environments. We want continuous integration solutions as a Jenkins to be able to target different projects that represent different life cycles for that application. And that's something we wanna come out of that box with. So source to image, this is a really cool open source project out there. If you just Google open shift source to image or STI, we sometimes abbreviated to. This brings up the main use case that we have, right? From a developer point of view, knowing absolutely nothing about Docker, absolutely nothing about Kubernetes to be able to just commit back off of a Git to either work in his IDE, see his project and have that rolling, right? Have that rolling of the Docker layers, identify a Docker layer, push it back to that Kubernetes pod, bring that pod relationship with the Docker linking, the overlay networks to the other parts of it, form that route, maybe it's a DNS route, if it's non-rattable DNS, all those things are just automatically happening for us. It also gives us a cleaner, more scientifically pure rollback mechanism. I know that I'm gonna roll back to a very specific layer of Docker, very specific image. And that's helpful for operations. So the other side of this is the platform, Kubernetes, underneath us, needed to be, needed some more intelligence to it around our use cases and that's what we're bringing to it, a more intelligent platform based on the things that we care about and what do we care about? We care about changes in source code, right? When somebody commits a line of code, we wanna recompile, relayer and push. When Jenkins wakes up off of a failed or a working smoke test, we want that to work. When a vendor provides a new binary in his Docker hub to update his application, we want that to wake us up and do the redeployment. So we're doing a lot of automation around a lot of the things that people who use PAS care about. They care about their binaries, their applications, their source code and their continuous integration code the path to production. That's where we wanna live and that's what we wanna provide. So at the end of the day, we want a very repeatable and a very fault tolerant across that form in a very automated process as you move your applications around. Where we're focused on spending our R&D is around this triangle, this layer. It's really around the spanning of infrastructures, right? No longer are we seeing people that are running in private and public and we've seen that for a couple of years now. We see people who wanna actually span both private and public with a business service and that's bringing new and exciting opportunities to the forefront. Containers, we've always been about containers and we'll always will be about those containers. We find the atomic project to be extremely exciting in the fact that we have so many kernel engineers working on that and making our platform pushing a lot of that intelligence we had in 2.x into that host. We get to just capitalize on that in a more fluent way, different lowers that operational cost. Microservices, breaking up teams, breaking up monolithic applications, forming independence of features. I can take, I can risk mitigate as I move into continuous integration delivery if only one part of the larger application fails and that allows me to really push the needle and get to that market a lot faster. Dev Ops is basically finding tools that give me a way to define the relationship between two working groups, to allow operations to guarantee the qualities that they want, that resiliency, that uptime, that efficiency, that utilization and then have the devs hop on and be able to think they have full control over that. I have roots, I have all these other abilities to see log files as if I'm on a real operating system and it's a trapped environment. So Dev Ops is definitely fluent, moves into a larger value add such as continuous integration and continuous delivery and that's part of the triangle that OpenShift wants to be a part of. So as we look at our community, this is the community components that we're looking at bringing into the comments, right? The people who we have a lot of CCPs, what we call cloud providers joining the comments, you'll see and you'll hear their voice and what they want out of it. You'll have companies that are into that Docker ecosystem that wanna make sure that their images run on the platform so you'll be able to hear from them. We have microservices, we have a, we're at the forefront with our Fuse portfolio and our new feed Henry acquisition of moving to a lot of these architectures for applications. We're bringing a lot of people in their communities into the comments. And then on the DevOps, we've historically had a strong DevOps presence within the open source communities that follow REL and Fedora and CentOS and we find them joining the comments. So you'll get to hear at each one of these layers a lot. So call to action. You know, I already mentioned, totally hit that email, alias, introduce yourself but I wanna give you some ideas and start chatting about, start kicking around some ideas, where we should go. But in order to do that, you guys have to get your feet wet. So definitely hit these URLs and you'll find there's an alpha one drop of the version three product. In 30 seconds, you're pretty much gonna stand up with Kubernetes Docker and that source to image solution without knowing it. Not knowing anything about it. That blog will actually walk you through the steps. You just copy and paste these commands and you'll get a good feel of what it feels like to stand up a pod that has a Docker repo and have to pull an image to subscribe to a web hook and I'm gonna get hub for a code change to have that code change. Go ahead and re-layer an image for you to go ahead and add that image fail and then have the replication controller bring it back online. So these, you'll get to see all those components working already in the dev concept alpha one drop. The next drops are coming. We'll have one once a month. So December's will be coming up here. We'll add that project concepts and the multiple users. You'll get that RSE command line back. You'll see multi node deployments right now in the alpha one. It's pretty much on one laptop that you'll be working with and be able to add in more minions. You'll get the platform router. You'll get a Docker repo integration that's outside of the product. And then in January, we'll bring in that browser user interface. We'll talk about more of these Kubernetes components that we can integrate and leverage. And then we'll talk about the Docker layering control. So definitely start with alpha one, get a feel for it, get excited about alpha two coming out and then alpha three. Then beta will add more features. The beta is pretty much what we think in our minds to be a true replacement for the 2.x product and which features it's penetrated into. And we see that starting towards February. And then the shipping product is targeting right now, things change every day, but right now we're targeting for the middle of next year around that June timeframe. So things that we can talk about. DNS has been a big point of conversation with all of our on-premise solutions, not so much the public ones because we take care of that for you, but integrating with DNS. And we're thinking about adding this ability to have non-DNS routes if you wanted them. Just basic IP based routing. So we wanna hear if you think that's a good idea. Another one is environmental variables, right? And PAS, we use environmental variables quite a bit. And it really allows that magic of auto-binding cartridges together without developer needing to know how to add Postgres to the EAP. We can pretty much take care of that for you through environmental variables. What we're thinking though is making them a little more secure and allowing people to have secrets. And this will be using maybe more like a traditional hypervisor key store. If you're familiar with Zen, it has this ability to have something in the main host, some information and have that call through a TCP socket encrypt it up to the guest. And this is a way to have more defined secrets across platforms that our cartridges or in this case, our Docker images can start using. So that's another one to start talking about. Evacuations has come up. Right now you can totally move gears around in the 2.x platform, but it's a couple commands, right? It's identifying what the gears are, it's stopping them, it's then moving them and bringing them online somewhere else. We've had some people say that we wanna one click evacuation process. So we're interested in hearing what do you wanna evacuate? Do you wanna evacuate entire availability zones or is it really just one node to another node? What types of evacuations are you interested in? The idler, right? This is a huge feature for us. Not a lot of past providers offer it, but pretty much in the 2.x platform, what we end up doing is holding the URL to your application up with that HA proxy, shutting down that gear if it hasn't been HTTP requested and over X amount of time. And then when a request comes in, they're gonna hit that URL that we've been holding and then while we're holding it, we'll bring up the gear. This allows a huge density, right? This allows us to run with active max gears of around 75 where traditionally you would think that was crazy. What improvements do you want in the idler? Are you using the idler? Have you seen problems with the idler? Where do you want us to move? Another big one is continuous integration and delivery and that really revolves around Jenkins right now. There's pretty much three use cases around our Jenkins interaction. One is I have an existing Jenkins and I want to just use post-actions after tests have passed to push out these artifacts to open shift to the platform. Another one is the one that we support out of the box and this is us standing up at Jenkins, right? An individual developer can choose at any time that he wants to add Jenkins to his application. He doesn't have to know anything about Jenkins. We just give him that cartridge, he adds it and then when he builds it, builds off on the Jenkins and it'll push that to his environment when it's done the binary. Have you had problems with that? Do you want to see more extensibility in what we're offering out of the box in that area? And then the third one is if we were to have an external Jenkins, would you want it to use open shift, has build slaves and then push? That makes it a little bit different than the first one. So those are the three areas that we're kicking around around the Jenkins use cases. If you favor one over the other, let us know. Let the community know, let's have a discussion about it. So that's an example, yep. There's a couple of questions coming in if you're ready for those. Yeah, let's get the questions. They're in the chat, but Joseph is asking what would be the recommended OS, RHEL 7, Fedora 20, 21 for development? I have my personal opinions, but you can go for it from product management. Right, so I mean, we love RHEL 7. That's what we're gonna make sure it works on, but the Fedora 21 is a good candidate. I think, Diane, do you know what we put out on origin or openshift.org? I think we're using Cento 65. And that's what I've been testing with in Cento 7. Great. Any of them should work on those. So the other question was. Any thought on Go as an alternative to Jenkins or Go CD? Yeah, so in terms of shipping out of the box, we were still favoring Jenkins, but we found over the last couple of business quarters is that there's a huge market and continuous integration delivery. There's probably over 20 companies at this point making quite a bit of money, so they're quite large organizations. We wanna make sure that we're open to all of them, that we work with all of them. And it really comes down to that API at the end, the post-action APIs. So we just wanna make sure that our REST APIs are callable in a fluent manner with whatever anybody else is doing. But for the most part, I think right now we're gonna stay with Jenkins for the out of box solution that we provide. Again, I'm not seeing any other questions. I'm gonna say that if you have questions, you can always ping someone on the IRC channel on OpenShift or OpenShift-dev. And we highly encourage you to post it to the OpenShift-Commons mailing list, which you should all be members of. And if any of you are not, just give me a shout and I will add you in. I think we've got most of you on there. And please do introduce yourselves there. Wait and see if there's any other questions that come in. And I can see Romain in the dark there. But I'd also encourage you to visit the landing page for OpenShift-Commons and click on the SIGs. And if you're interested in joining either the Ops or the V3 SIG to get on those mailing lists as well. And we can further send out some more information to you about that if you've got questions. Let's see what the chat holds here. All right, there's another question here. For Enterprise, what's the timeline for Java middleware? Do you have one there? Great. Yeah, so the Java middleware, well, the goal of the release is to make sure we have the exact same content that we're providing in the 2.x and the 3.x if not that, then more. So when we look at the Java middleware stuff that we were providing today, we totally foresee that being in Docker images around the time that we release. More importantly, the app server, the Tomcat derivatives. And then moving into third parties, when you look at Docker, as more and more companies adopted, you'll find more and more officially supported solutions instead of things just provided by the community. So we think June is a good time frame to start seeing a lot of that content. Right. And I'm not seeing any more questions at the moment, is anyone else got anything else? All right. Well, thank you everybody for joining us today. And a special thank you to Mike Barrett for doing this session, because I know he did another one earlier this morning. And so he should be ready for a nice large glass of water, hopefully, and we'll be doing another one next week. I think we're doing OpenShift on OpenStack and we'll send out that the invites and the information for signing into the Boojins to the mailing list as well. So please do pay attention to the mailing list and we hope to have you all back here and help you get through to V3 and help you give us feedback, make full requests and start taking part in the commons conversations. Thank you all and thanks again, Mike. Thanks, Mike.