 Welcome, everybody, to this very first OpenShift Common Briefing of 2016, Diane Mueller, and I'm the Community Director for OpenShift, and I'm really pleased to have with us today Pete Muir and a number of his colleagues and friends from the Container Development Kit or CDK project, and we've been doing lots of work trying to improve the local container development experience, and they're here to talk through their approach to it and hopefully get your feedback on it. So I'm going to let Pete pick it off, and as people join, they can introduce themselves. Thank you, Diane. So the kind of agenda for today is I'm going to spend about hopefully 10, 15, maybe 20 minutes talking through kind of what we see the problem to be, what the goals of the work that we've been doing is, and then kind of give you an idea of, you know, in a little more detail about what we set out to do in order to meet those goals. I'm then going to hand over to a couple of colleagues who are going to give you a demo of what we have so far. So I'll start by introducing myself. So my name's Pete Muir. I work for Red Hat. I'm the Engineering Manager at Red Hat for Developer Tools, and with me we have a number of people from the team, but in particular speaking are going to be Max Anderson, who is the Architect and Lead for the tools that help people build and deploy applications, and then Fred Brickon, who works on the OpenShift tooling, inside of Eclipse. We also have a few other people who I'm sure will be contributing via chat, and perhaps answering some questions at the end. So before we get started, I want to give everybody a kind of an idea of where we are in this journey. When Diane asked me to do this, she was very clear that you guys like to hear quite a lot about what's coming up, that what we show you could be pretty rough and ready, but you'd really like to hear kind of an idea of what's coming up. So we're very much here in that vein. We're very much here to say, look, this is kind of what we're working on. I would describe what we have around alpha quality at the moment. We're working hard to move that into beta and beyond, and through to GA. But it is rough around the edges, but the goal is to show you the direction in which we're headed. The team has been doing an amazing job of putting it together. The first time we really managed to get an end-to-end flow on the demo that we're going to show you was a couple of weeks before Christmas, and obviously the team was mostly off over Christmas. So I think we're going in the right direction. We've got really good velocity going in that direction. So like I say, earlier adopters at the moment, but I definitely encourage people to check it out. So with that I'll get started. I'll try not to talk too much and for too long and get on to the meet, which is the demo. So if we could go to slide two, please. So I wanted to start with a kind of a quick problem statement. We're the developer tools team, so we really care about making development, development of applications easier. We see containerized applications as probably one of the most important trends in application development in the industry for a very long time, because of all the well-known benefits of containers, of Docker containers. But we also recognize that this is a new technology, and at times it's been really hard to actually build applications. Many of us are kind of conveniences that we're used to, when we've built applications to run on bare metal, kind of got lost in the containerization effort. So it was pretty hard to get started with at times. And it was also pretty slow. There were some really long turnarounds when you would have to change your code, test it out, build it into the container, get the container running, and see those changes running. You know, that goes from, you know, so my background is with Java middleware, so something like Javasab server, you know, when I'm running on bare metal, I can get a turnaround in two, three, four, five, ten seconds with the application restarting. If I'm doing that in a container, that can go up to minutes. We are really concerned about that, because we know that the kind of the code debug cycle that people work through needs to be really fast in order for developers to be productive. So the problem we're trying to solve is how can we make it easier to get started with, so there's no barriers to entry, and how can we make it really a really good environment for developers to work in. So if we want to go to slide three, our goals, like I said, pretty simple. It needs to be really simple for the scenarios that we define, which is kind of this, you know, getting started scenario. We focus very strongly on Java and on JavaScript. Those are our two focus areas, and particularly focusing, I guess, on kind of microservices, the apps written using Java. Secondly, it's got to be really fast, so it's got to be really fast to write the debug code. So those are just the two goals we were trying to achieve with trying to set out to solve for this work. So if we want to go to slide five, I now want to talk a little bit more about what we've been working on and kind of, you know, who the target audience is and why it might be relevant, or why it's relevant to you. One of our, you know, one of our guiding principles in the developer tools team is that, you know, we're quite opinionated about what we do. So we know that we want to produce a really productive, really good developer experience. But we know that, you know, if we try and do that for everyone, that's going to be really hard to achieve. So we try to be really tightly focused on some particular types of users and some particular scenarios to try and really optimize for those. So the scenarios that we wanted to optimize for, in this case, were JavaScript and Java developers who are running Windows on their development machine and are deploying to a Docker-based environment such as OpenShift. And, you know, we think OpenShift is definitely the best Docker environment to deploy to, so our focus as the Docker environment was on OpenShift. So that's the target audience, JavaScript and Java developers running Windows on their desktop, deploying to OpenShift in production. So if we go to slide six, let me start to talk about what you get in the box when you download the work that we've been doing, when you get hold of the work that we've been doing. And you'll see this in the demo in just a few minutes. So we, in order, you know, if you remember our goals, our goals, our first goal was simple. So we wanted to make sure that everything you needed to build your Java application, your JavaScript application, was included in the box. And so for us, that meant we included JBoss Developer Studio, our IDE, OpenJDK in order to be able to run the IDE running on your Windows machine. We included the Container Development Kit, which gives you access to an OpenShift environment that's running on your local machine. We include Vagrant in order to get the CDK up and running and VirtualBox in order to run the virtual machine that CDK runs in. This all comes in a single download, a single installer, and it runs, like I said, on Windows. So what, if we go to slide seven, please. So what scenarios is this optimized for? And this is where we come back to, well, both of our goals. So it's optimized for running JBoss Developer Studio and OpenJDK running on your Windows laptop, which then communicates with an OpenShift that's running inside a virtual machine where you can interact with the lifecycle. You can use the source to image capabilities, and you can interact also with it using the GUI and the CLI. And then we're looking at applications which are running inside Docker containers, and we were particularly focused on EAP, JBoss EAP applications, and Node.js applications. So if we go to slide eight, please. So why should anyone care about this? And I've kind of talked about this a bit with the goals, but let me just reiterate. We wanted this to be really simple. We wanted this to be as simple as being able to do a Docker run, CentOS, WorldFlight. So we wanted this to be a single, install or a single downloadable that you could get hold of. And then once you've got it, we want to offer you the ability to really quickly deploy your code and really quickly debug your code when it's running inside that Docker container. What was kind of our conceptual journey? How do we think, what do we think the steps that you needed to take in order to get started should be? And then you can judge us when we do the demo on how well you think we've attained them. So if we go to slide 10, please. So we're seeing that you were starting with pretty much a bare metal machine. So your first step is to install Windows. And our target really is Windows 7, 8, or 10, running on your laptop. We can go to slide 11, please. The next step you need is to get a redhat.com account, and you need to be able to sign up for the $0 developer subscription. And this $0 developer subscription is totally free to anybody who wants to use our software for development. And the subscription will contain the CDK, it will contain Atomic Coast, it will contain OpenShift Enterprise, and JBLS Developer Studio, all the components you need to get started. This subscription isn't quite launched yet, which is going to make it somewhat hard to use right today. But like I said, we're working on all of these items and getting all of these done. So if we could go to slide 12, please. So having got your redhat.com account, the next thing you need to do is download and run the installer. So the installer will install the components we talked about in the box, so JDK, the Container Development Kit, Dev Studio, and OpenShift Enterprise. Go to slide 13. The installer will then also ask you to enter your redhat.com credentials so that you can then update and run any updates and then install any additional software that you need into the environment. Go to slide 14, please. The next step you need to do is to be able to start your development environment, run JBLS Developer Studio. Slide 15, please. And then obviously you want to be able to use a sample application. So you have the ability to select from some common applications, some common sample applications inside JBLS Developer Studio. And this should run straight away in the local OpenShift environment that you're using without any additional setup. And finally, of course, we want you to be able to change code and see those changes reflected quickly in your running application. So that was our goal. That was the kind of really what we set up to do, a really simple, easy to get started experience and then be able to see those fast code changes. So with that I'm going to hand over to Max and Fred, who are going to take you through the demo and show you how we've worked towards some of these goals and see how much easier I think we've made it in order to get started with this local container developer experience. Max. Hi, thank you, Pete. So this is Max Anderson. As Pete said, I'm the architect behind the deployment and coding in our developer experience. In the past, I've been leading the Developer Studio work. So if you've seen me talk about Eclipse against, that's what I'm doing the last few years. But now we're going into more Eclipse tooling and beyond for this container tooling. So I'll show it in the installer. Yes. We can't see any screen. No one's showing it. At least a bunch of us can't actually. Make sure I'm here again. Yeah, there you. You're back. We're receiving your presentation slides, but not your desktop. OK, but I'll come to it in two seconds. OK, Diane, we're not seeing the slides, though, either. A bunch of us are seeing the slides. Is it supposed to be in BlueJeans? It's in BlueJeans. BlueJeans, right now there should be a video. No, like Mark Borschstein, myself and Xavier, none of us see anything. OK, let me. The presentation is going out. It is. I haven't seen it. I mean, I see the video. Yeah, I haven't I haven't seen anything. I'm OK. As far as I can see, people saying they can see it. OK. You would unlock it when it looks like. Yeah, there's some of us that are unlucky. So just make sure that whoever's it's being recorded and I guess we'll watch it later. Maybe it'll be available then. Yeah, OK, cool. Sorry for that. By the way, I'll show the installer. Then I'll hand over to Fred for doing the tooling workflow and we'll come back to me. I'll summarize what was shown and some of the things that we couldn't fit into the demo or we haven't published enough to show off yet. So again, what you're seeing here, I'm showing a video of the installer because actually running the installer takes a bit of time because it's a very long time. I'll walk you through. So first of all, when you have the installer, you'll have to log in with your username and password for the developer, Red Hat developer account. And this is purely just to get access to the productized binaries like Omshift Enterprise, the CDK that has a Docker and atomic in it and Debra Silver Studio in there. So once you've logged in, it will, of course, verify if you haven't, don't have access, it will tell you to go and create them. So I'll just pause here for two seconds and you'll see this is the first page of the installer. It has the OpenJDK V8 that will run on Windows, Red Hat container development toolkit, which is called CDK. This is where we have Docker and Omshift and a base OS to run on your Windows machine. Then Red Hat developer is going to run on your Windows machine. Then Red Hat developer studio, in this case is version nine, which will have all the Eclipse tooling for doing Java E, JavaScript development and now container target development too. And then finally, inside there'll be Red Hat Omshift Enterprise. If I go further, you'll see a little bit of details. It will start downloading all these things in the background. We also have install have everything bundled. It'll probably be a bit bigger. It will start installing like CDK, Raygrind, VirtualBox, JDK, JBS and Sikrin in this case, which is to get stuff like R-Sync and SSH, which you need to talk from your host, in this case Windows, to Docker and Omshift in a nice manner. And I'm just going to fast forward, because this will take some time and there's no fun in doing that. Live. So once you're at the end and you're running on Windows, you get it in the folder here now called platform, it has everything in it. CDK, Sikrin, JDK, Raygrind, VirtualBox. And we put it there so it doesn't conflict with anything. Just something to be able to run on any machine. And the whole idea as PDF-rated is that all of this is just kind of configured to work together. So the CDK works on its own, but the IDE is set up to be able to know where these components are and talk to them. And that's the installer. Yes, that's all the list of the installer. And now I'm just going to drop back and hand it over to Fred, and Fred will continue from the Eclipse site. And then I'll be back in a few seconds. So over to you, Fred. I'll stop sharing my screen and you should be able to take it. All right. Can you see anything? Yes, we can. Right. So I'm unfortunately not running Windows, but it's pretty much the same thing. Once you're inside JVDS after the installer completed, the installer will have created something called a CDK server adapter that will be shown in the service view here. So that CDK server adapter basically allows us to start and stop the background file that starts the CDK itself. So once I started what will happen is it will spin up the OpenShift instance and we'll also be able to show the Docker registry inside the CDK. So let me just start it. So the first thing it asks me is the password for my Red Hat login. So typing it. And once it started I will be able to see the Docker Explorer in the Docker Explorer view. I can see the CDK server adapter Docker registry that contains some containers running. So this is basically the internals of the OpenShift instance that's running. I can see containers, images so a lot of things. So the Docker tooling allows me to use the Docker registry to pull images if I want. I could search for wildfly images instance which then files without a type will be better. There you go. I can select the image select the tag I want to install and click finish and it will pull the image in my Docker registry. So yeah basically the internals of the OpenShift instance that I'm running from the CDK. So on the other side in the OpenShift Explorer you will see that I have a new connection to the OpenShift local OpenShift instance provided by the CDK. So in that in that instance I have a couple projects to contact and my goal now is to deploy a Java E app onto OpenShift. So this is my local cloud environment running on my laptop. So in order to do that what I can do is pick any kind of project from the Java central page which allows me to access at least say 200 examples. So if I want to create a REST application using the JAXRS framework I can select, for instance, hello world RS and it's loading the media data it will take a couple seconds and the wizard tells me that this app runs on EAP 6 or 4 or Wildfly and it works best using the Maven CDI contributor. So I will not complete the process here because it takes a few seconds and I already have it in my workplace. So this app is a Java E app using REST endpoints and CDI as a dependency injection framework. So the tooling that we provide allows you to quickly navigate through the REST endpoints. I can click on the Project Explorer view on these endpoints. I can debug, run them on debug mode on server for instance here there's a web service tester provided by JBS I can click run or I can test the JSON endpoint and the response body outputs the results. So this is my Java E app runs locally on my local JBS instance. So now the goal is to run that same web app inside OpenShift. So how to do that? It's as simple as saying configure deploy to OpenShift. Now in order to do that so this is the stunning page to OpenShift you need your username and password. So now in order to deploy your app there's one major prerequisite this project needs to be shared with Git so that the OpenShift instance knows where the source is the source lives and so it can clone the repository and build the sources. So I've done that before creating the after creating project before the demo. Now that I have my selected project because this is a Maven based project it has a pomex ML the wizard will filter the available templates on OpenShift using the EAP keyword I can select any other kind of template if I want. So in our case I'm going to just stick with the EAP64 basic S2I template. It's a template that basically runs the same EAP server but on OpenShift. So here in the template parameters I can see the source repository URL points at my personal repository on GitHub. I click next finish and the application has been created on OpenShift so in the tag refresh there demo goes where are you okay so in my tag projects my EAP app is running the build is running so what I can do is open the build log to what's happening and I can see the the Maven app is being built. So it's going to take a long time about five minutes so in the meantime we can do some other things probably we can take a look at what the OpenShift Explorer provides so we can have access to build logs but we can also take another app for instance one that's already deployed and you show in Web browser and in that case I have a Node.js app that's running on OpenShift on my local machine. I can also show the same project in the Web console so this is the OpenShift console so if you're familiar with OpenShift then you will be at ease here and another thing that we can do is edit some configuration so in that case my Node.app points at the OpenShift repository so I want to change that to use my own fork I can edit the config and click check the source change it to my fork, save it and it will see the OpenShift Explorer the big URL change to use my own fork so I don't have it in my workspace but I can import my app that app in my workspace and do import application it should take a few seconds there next clone location finish and there I took the sources from the app referenced in my OpenShift app and imported everything in my workspace so what's the status on my EAP app build seems to be complete pod is running pod log the server is started started in 70 seconds so let's see if it's already running showing web browser there it is so that's one way to deploy your local project on OpenShift but it takes several minutes so the turnaround is not really exciting but we can do better so I'm going to demo now how to get incremental deployment in a really much faster way using the Node.js app so what I'm going to do is pretend I have a local server for Node.js so I'm going to create a new server it's an OpenShift 3 server still selecting my server my OpenShift connection and so I select my project this is the source class of my project and basically what's going to happen is we're going to do a our sync between the local machine and the remote pod on OpenShift so my my service is Node.js quick finish so my server is created I can show in the web browser still running okay so let's do some changes here in my index page we're going to change the title URL publish so it's publishing done and if I refresh it the app has been refreshed so it's much faster to work that way using the OCR sync feature that's hidden behind that OpenShift server adapter we can do even slightly better here I had to refresh the browser manually but I can also open that page in a live reload server so basically the live reload server acts as a proxy to the OpenShift server so I got a URL here I got a local URL and every time my browser receives a query it will transmit the query to the server on OpenShift and every time I do a change a publish every time I publish something on my server the OpenShift the live reload server will refresh the web page directly so let's see how it looks refresh automatically so currently we still need to manually do the publishing part but eventually we'll do the automatic publishing as soon as you save your file so that's a way to get a much much better turnaround while developing your app on OpenShift so we deployed our EAP app earlier if we look at the images on the Docker registry I can refresh them and you can see the Docker image has been added to the Docker registry matching my EAP app so that's about it the current status of the Eclipse OpenShift tooling and back to you Max thank you I'm just trying to find the share screen again go and you should be able to see my screen again so what Fred was so good to show was the Eclipse tooling so I did first the all-in-one installer that again takes all the bits you need for your Windows machine and get it up and running it saves you time you don't have to spend time on setting up both Docker break and the whole the whole shebang and then when everything is set up it kind of just works Max I can't hear you at the moment you cannot hear me why can't you hear me I can hear you okay someone can hear me okay I'll go on Max okay I'll continue so everything just works the setup you start up Eclipse it will know about the VM you have running we installed it will know about the CDK the vacant file that is used for starting it it will know about the Docker and OpenShift that comes available when CDK starts up and you don't have to set anything up inside Eclipse and of course there is the actual container tooling so which Fred showed like for Docker and OpenShift etc he also showed that we have a bunch of OpenShift ready quick starts if you use Javascript Studio in the past or been on develop.javas.org you've seen some of these quick starts in the early form working on both locally and OpenShift v2 these are now being expanded also to cover OpenShift v3 beyond that he showed to take one of these quick starts and load into Eclipse meaning it was an existing Eclipse product that was not an OpenShift but then take that existing product and deploy up to an OpenShift instance now in this case running locally on your CDK if you know OC the command line this is similar to what OC new app does but just in Eclipse setting but now where it becomes real is the incremental deployment so what he did show what we have working now is incremental deployment of Node.js because as you noticed actually the first deploy on the Java eApp might be a bit heavy especially if you are doing the full Maven build the full Docker etc but so we wanted to spend some time on making the deployment of Delta changes efficient so in OpenShift there's a tool called OC sync which allows you to mentally take changes from your local file system up to an OpenShift instance and what Fred showed was using that behind the scenes in our server adapter to do for a Node app and then to get to the Node app he had library load running so when he did changes in his IDE they reloaded in his browser once they had published to the server and if you come from a local deployment you go like why is this interesting like we've been doing this for a while but that's exactly what we're trying to do make sure that what you've been able to do on an OpenShift instance whether that is the CDK locally here which the turnaround should be decent or if it's in a cloud where it might be a bit slower because of network latency etc but anyway the idea is the local OpenShift deployment you have you get almost instant feedback similar to what you have for local deployment via this incremental deployment using OC sync and then the library load that we've had for a while but it's all integrated now in the ID tooling and in OpenShift so a few things that we didn't manage to show you here but we are either already have but couldn't fit into the demo or be planning though one is the incremental deployment of Java EE so again we saw that rather slow first deployment of Java EE we want to do the same thing using a local build and the OC sync over so we can do the Java class HTML, CSS, JavaScript etc replacement but on top of that if you know Java sometimes we change classes these changes doesn't take effect immediately this is something that when you run locally we can just kind of restart the container and everything is fine sorry restart the application container but in the in a Docker scenario or in a Microsoft scenario this might actually take longer for some cases so we've looked at integrating what we call hardware load of Java so if you know things like spring reloaded or jrebel that kind of functionality we are looking at embedding into the tool set into OpenShift with a few things that is optimized for EAP so you get the right you only get restarted things you actually need and again this is all to make sure that when you change something in the development environment you can see the change fast without having to wait for too many redeployments another thing is when you have Docker images you might have your own Docker image you have running locally or you have it on Docker Hub you can also take these Docker images and deploy to OpenShift from the tooling even more is one of the things the thing we don't have yet but really wanted to do is when you have this local setup in an OpenShift application running locally how do I make that run on another OpenShift instance but luckily because we're using Kubernetes this should just be about taking your application and the descriptors from Kubernetes and deploy it to another instance so you want to make that easy too oh and I skipped one sorry for that another one we have is Java and Node.js debugging we have already today you can put forward to so when you're running in a dark container OpenShift there will be stuff that is you know shielded off for your local environment we've made so our containers can be run with a certain flag so they enable debugging and then the tooling can connect to it or any other Java debugger for that matter can connect to it and you can use a debugger as you're used to but we're also doing it for Node.js and today if you're running Node.js on OpenShift it will run let's call it production mode meaning you'll have to restart the full container to see changes to your JavaScript but you can do changes to HTML and CSS just fine but not for the JavaScript code which is kind of you know the thing you want to change when you're doing Node.js so we've extended the Node.js containers on OpenShift to have again a similar flag we can set so when you run the Node application the IDE can do OCSync it will see a change and it will restart the Node.js container not the whole setup meaning you won't lose you don't have to wait for anything there on the OpenShift site okay that's kind of the additional plant features another one is we've focused very much on Eclipse in this presentation but if you don't use Eclipse well the great thing is all the tooling we actually showed Eclipse didn't use anything customer specific it was all using standard Docker protocols OpenShift APIs etc and that means existing tooling out there whether that is Docker command line, OpenShift command line OC, Cube control, all that stuff you can run on your Windows instance and connect to the to the CDK there is a vegan polling plugin called Reagan ADB Info which will dump out the information that is necessary to set up these command line tools if you try things like the Docker machine or a vegan inbox that this works in the same way you just get these environment variables which then other tools can use and connect to if you are a non Eclipse user or a command line user or IntelliJ or something else and they have similar tooling this will work with it too and finally the CDK is basically a little pre-configured Linux VM meaning you can do vacant SSH into it and then you can access it as you want as a Linux mindset if you want that okay so how to try this out now as Pete said in the beginning this is kind of alpha quality there are some parts that are there now especially the Eclipse tooling that Fred was showing this is all something you can try today use that against existing Docker or existing OpenShift instances the part that is not in a easy to download available today thing is the CDK package in a way that has OpenShift in it but you can get the source for it it's all on github.com that's tooling OpenShift Regrant as it's on the slide and then finally the whole installer also the source growth for that is available it's actually an electron app if you are interested in that kind of thing I just want to just point out that currently the downside of these builds is they depend on binaries only available inside Red Hat now but it can give you an idea of what you are working on and we will update these repos and this is actually our master repos so you can see what we are working on and give feedback once these things come out okay and that actually brings us to the end I'm not sure if Pete have any final comments I just want to say thank you very much to both Max and Fred for a really good demo that was really informative for me definitely so I really enjoyed that thank you very much it was definitely informative and it really you guys have made a lot of progress since the last time I saw this probably November last year so it looks really very interesting if people want to give feedback what's the best method for them to do that so we have on the slide the Diabas Studio Forum you can post questions there and otherwise on Twitter we are on Diabas Tools and you also listen to questions on the ad open shift so you pretty much one of the questions I was going to ask you was what were the new features that are coming and I think you covered that often the last couple of slides so thank you for that there was an earlier question by Marcus but I think you also unmute him and around the dependency on GitHub but I think we covered that off as well I saw one I saw a question about why we don't allow the product to be mounted from the product to be mounted from your host the laptop workspace into your open shift container so you don't have to commit to the git repo and redeploy every time so this is actually I can answer that in a bit more detail than I did on the chat the biggest two parts here is one is what you suggest there Marcus is perfectly doable especially in a Docker world where the Docker is running in on your machine you can do what's called a mounted volume the downside currently is that if you're running on Windows doing mounted volume shared volumes is actually not very fast and there are some tricks to it but you can actually do it I can maybe add a few comments to the slides some blogs we did six to eight months ago about how to actually do that from the tooling today so you can do that in a Docker scenario when you do go to OpenShift we'll be actually running in a cloud or a cloud like environment there'll be multiple parts that might need to be synchronized to it's not just a single place there is network stuff that might not be easily available for us that's why as Fred showed and I talked about we use this thing called OC Sync which will basically take it'll use our sync behind the scenes to take an efficient delta and copy over to the container and that basically does the same trick so you don't have to do the git commit etc so I hope that answers the question that why are we not oh rather why are we doing more than just mounting the volume I'll also add that maybe from a kind of a higher level perspective I think this, so the problem that we're talking about here is how do we get the files from the person's local workspace into the application that's the kind of fundamental problem we're trying to solve and how do we do that quickly and I think we recognize that that is a real problem that definitely needs solving that was a part of the original brief for this initiative that we've been working on here it's still something that we need to address better whether it's done best by mounting volumes or by running a git server locally that people can push and pull from I think there's multiple ways to solve that problem of how do you get files from the workstation up into OpenShift I think both we and the OpenShift team all recognize that this needs to be much easier than it is today so these are pretty much transparent and quick but I don't think we've really focused or fixed on a particular solution today I think there's a variety of solutions that we could look at there is one last question here Peter Larson is asking is Tomcat supported as well so the stuff we've shown works too on a Tomcat setup so this will work with a Tomcat like Tomcat OpenShift support image alright let me again just come in briefly on that to explain our philosophy and I talked a little bit about this at the beginning but our philosophy is we optimize for certain scenarios we support certain scenarios as a company as Red Hat supports certain scenarios and then there are other scenarios that are possible so for us that EAP path and the Node.js path that Max and Fred showed that's kind of our optimal path and that's the one we're really focused on in on kind of laser focused on there are others that we definitely support such as the Tomcat one that was just mentioned is that the one that we spend most of our time and we really push the QE team to make sure they're really doing a great deal of testing that is that the one we show in demos is that the one we document the hell out of no but it should still work it does still work and we still support it and then there's things that are possible things that should work we do a little bit of fiddling to get them going but they should work in there so I think from my perspective it helps to always keep that philosophy in mind and that explains why we always show particular paths through the tools and we've got another couple of questions Ramon is asking how about monitoring with JMX and the container any way to connect mission control or something similar to the pod so I can answer that the main answer is yes you can do that currently it requires you to you basically just have to have port forwarding there are probably two parts you have to port forward to the container and the container has to expose that port so you can do it manually today we actually have kind of mission control light features in the other tools that I would like to enable in this application but currently it's a manual process but you can do it I hope we can find a way with a talk with the OpenShift team that we can actually because we're running in a local environment we can do a bit more tricks than in a full blown OpenShift so we can basically do what's called a docker exact behind the scenes to open up these ports but this is just kind of ideas but technically it is possible but right now it's a manual process there was one last question how much resources are used by the CDK VM CPU and RAM so I think Brian answered I think even the one we're using right now we're actually using less like one and a half gig we've set up and two CPUs but yeah we have a default right now we haven't tuned it but yeah it'll be somewhere between one or two or three but the idea is we'll have a default and you can override it if you want to depending on your experience what kind of large application you want to deploy let's see that was almost before any template tooling on scope any template I don't understand the question that one so in Ramon you want to clarify that I think that's referring to Kubernetes OS for building a template we don't have specifically template tool like advanced tooling plan on this area but what we have recognized is we're going to add we are working on adding a JSON editor to the Eclipse base which allows us to have content assist basic validation based on JSON schema that alone will become a bit nicer to edit if you notice the editor that when Fred was editing the config that was actually a syntax highlighted editor so that's kind of the pre-cursor of this JSON editor but the fact we can add the JSON schema to it means stuff like content assist becomes better and we are working on making that extendable so we can add like OpenShift specific logic to aid the user there but that's about it at the moment but yeah it's something we discussed but nothing specific beyond what I just mentioned okay and the one thing that everybody always asks for we have a roadmap what is available today in six months and later and I had also asked earlier if there's a Trello card tracking that you could share yes so there is a Trello card Pete will add it to this at the end of slides here more specific roadmaps right now it's a bit spread out I'm not sure if Pete knows anything but right now it's spread out between jbds and the cdk area but yeah you have the Trello yeah so we're still as you can see working on getting this right I don't have a sort of dates that we can give at the moment unfortunately that's one of the things we need to work on is the dates but as you saw this is made up of a number of different components quite a few of those components are released reasonably frequently so things like the jbds support I mean max you can definitely talk about when the jbds support for some of the features that we saw today would be going GA as for the cdk GA release date I don't have we don't have that immediately available at the moment and I believe the oc sync support is in Openshift 3.1 yeah correct so yeah the GA of the tooling we showed today will be in March that's the plan and then we will start doing more over the summer and yeah those those dates and times are in our jbds you can set links for that there was a question about do you have integrated virtual box into your solution what about auto virtual license tech like VMware so this is a fun one in the sense that we had to take a pic of which one we want to put in there and right now virtual box was the one because it ran on it was the easiest to get going with for us and having a distribution and I think the cdk itself supports virtual box and one more but yeah Brian says libvert and others on horizon for this scenario here I think if there's one we would target after this it might be hypervisor for windows because if you run the people who are running windows that has hypervisor can actually not run virtual box so that's the fun of that so the answer is right now we are doing virtual box but we will probably do something more in the future which one is undecided I'll add to that what we showed you today was kind of we focused on that what we think of as the main path through the installer which is getting all of the core tools installed for someone who doesn't have them already one of the enhancements we need to do as we go through the beta phase is adding the ability to select existing components that you might already have on the system and also allowing people to use things like other hypervisors so the cdk supports a number of different virtual machines so we want to be able to make sure that we can allow that to be selected during the install process if you already have them installed I think that would be the key thing if you are using our single download single installer the one we are going to be able to install for you would be virtual box or possibly hyperv in the future if you have other ones already installed we need to be able to as a feature request for the installer we need to be able to make sure that you can select the one that you want to use and everyone else thank you very much for today if people from the community want to get involved in helping testing getting new features what's the best way for them to do that I would suggest going to the github repositories that we have linked from the slides we are pretty active in the issue tracker there so there are often long discussions on the issue tracker we have quite a few contributors from Red Hat who jump in and help out with getting things done there so that's a great way to follow along I think on both of those github repositories max linked following the pool requests, following the issues that's probably the best way to get involved today and otherwise we are also in all the regular RSC rooms on free note like OpenShift that kind of thing OpenShift and OpenShift-dev are very good places to ask questions and to give suggestions so attracting them through the issues is pretty cool and Ryan's just said for the CDK on free note join atomic and I'm going to say it wrong nucleol nulacule nulacule there there's lots of places there and we can all we can all help you get to the right funnel to get the feedback in so thank you very much everybody for coming today I look forward to when you go GA and have some more new features to showcasing it again and thank you Peter for joining us from that hotel room wherever you are and everybody else who joined it was very enlightening and I'm looking forward to being able to demo this myself next time alright take care and the recording will be up next week's session will be on an atomic OpenShift update with Mike McGrath and members of the product management team from OpenShift so that should be fun too so stay tuned thank you