 Good afternoon, everyone. I am Mohit. I work at Red Hat. I'm a senior software engineer there and I'm based out of India. So today, the topic we are focusing mostly on how to integrate the OpenShift integration with Visual Studio Code. As a normal developer, we have an idea to integrate different IDs, different command line integrations, and work with every other terminals inside our development scenarios. So as a normal developer, if I need to work on Kubernetes or say I need to work on OpenShift, I need to memorize a lot of commands and I have to work them on this different CLIs. Then again, I have to say deploy a Java application onto that OpenShift instance. I need to go ahead and code my Java scenarios in any ID, and then I have to deploy it back to the OpenShift cluster. So it's a two-and-fro scenario. So in this talk, I will be explaining that how to integrate the seamless experience for a developer, everything can be directly done and integrated using a VS Code Editor. So say you have a scratch VS Code Editor. VS Code Editor is basically from Microsoft and it's open source. So you just install a VS Code Editor, nothing is there and from Red Hat, we have developed an extension which basically integrates OpenShift into it. So you go to a Visual Studio Marketplace, you download that extension and you start working onto it. So basically today my talk will be more on the demo side that how things are working and less on the slides. So let's move on. So what problem are we going to solve here? So there's a scenario for a developer that, okay, it works on my machine, but it's not working on your scenario, then how we tackle it? So when everything is on the Cloud, you know if something is not working for you, it's not working for others because it's already there. So we are targeting solving that. So now for OpenShift, we have different clusters. Now one cluster can perform different operations. So we have a cluster which does a game scenario, which has a back-end on MongoDB and a front-end on, say, any web application, Angular, React, whatever it is. We have a different cluster which caters to Node and other cluster which caters to Java or say Go or Ruby or Python, whatever you have. So all those clusters can be seamlessly integrated at one place so the developer need not worry about what clusters is present at what scenario. And now after deploying those changes, now we make others changes into the code, we merge different PRs, we add fixed different issues. Now how to deploy those changes quickly to the OpenShift instance? This extension will help you do that with one push and whatever push is there, you can just watch the changes and that will be giving you all the logs directly into your editor. You will not go to a different command line to see what are the logs, what is failing, how the Jenkins is reacting to those logs. So everything at one place. So what OpenShift solution provides is, you can have a say S2Y image basically from a base image so that can be a Java, that can be a node, any application which you want. That can be from your local or say workspace folder which is there or even any code which is deployed on your GitHub. So directly first that code, deploy onto your OpenShift instance, make changes, push that code and everything is deployed at the end. And the last one is even you can do it from any say, you have a tar file which does all these scenarios. So you need not worry about do I have a source image or do I have a Git repository? Even if you have a tar file to it, just press that to it and that cluster will be up and everything will be running. So now from Red Hat has different extensions for VS code. So this one is basically OpenShift connector and this is available at Marketplace. I will be showing you how this works. The second extension which we have is basically an extension pack. That extension pack does is you have this OpenShift connector, you have different Java debuggers, you have different Maven plugins and those basically get integrated into it. So say you want to do a Spring Boot application from scratch to end. So everything can be done just installing that extension and moving forward. So this is the scenario how things are. You write your code in VS code, whichever language you prefer. You deploy that into OpenShift using the extension. Now once that code is deployed, whatever changes you make, whatever scenarios are there, just do a push and those changes will be automatically redeployed to that cluster. So for this we are using local instance of OpenShift. So right now we are using MiniShift which is running a local OpenShift cluster that is our open source and even we support the dedicated OpenShift premises which can be there. The second is CLI tool and the third one is OpenShift do tool which basically is at the back end which does all those operations. VS code is the front layer which performs all the operation but at the back end we have OpenShift do tool which performs all those push, watch, the lock changes, whatever cluster is there. You need to describe the cluster, what type of cluster is there. So everything on that. So let's go ahead and do a quick demo. Right now I'll directly go to how the different linking between the service and component works so that later on I can explain that how things are and how seamless this experience can be. So I'll just move the recording a bit ahead. So if you see this is a Git repository for a front end application. So I will use this Git repository to create my component. I'm not using a source image I'm not using a tar file. As I mentioned earlier, these are different scenarios. So right now I'm using this Git repository to create the front end. The idea behind this game is to have a Node.js front end which is using this open source phaser JavaScript on game engine and the Spring Boot back end application which uses the Red Hat OpenShift Java API to connect with Kubernetes and OpenShift. The back end service written in Spring Boot lists all the platform objects which we have running in our project. And the goal of the game is to shoot them and destroy them. Those objects can be different build conflicts, different pods, deployment conflicts, services, routes. And as we can see when we end this demo. So let's move back to VS code and go ahead and create a component for Spring Boot. For that I have this Git repository present in my local workspace. So go to the terminal in VS. So now the front end was created using a Git repository. Now the back end will be created for my local workspace. So right now I'm demoing difference in ways you can do it. Even you can have this repository and GitHub and just clone it and make it working as a component in your service. But right now I'm just showing it from my local workspace. And I built the binary for it. So NVN package. So this will start the build. So as you can see, I need not switch any different CLIs on any other instance to run this from my workspace. Everything is done directly from VS code. So you see the build is success. We have got that jar file. So let's go back to the OpenShift extension. In my application, I go ahead and I create new component. So there are three different ways to create components. One can be directly used to using a Git repository. One can be used using a binary file and one can be used from the local workspace. So right now as we have already created a binary file. So let's go ahead and use that. So once we select that, it asks us to select this binary. So we go to a target folder and we see this jar is already there. We select that jar and we say, okay. So now we need to name the component. So we name it Wild West backend. What is the component type? So it's a Spring Boot application. So we select Java. So now when you see these are the different component types. So when I started the cluster, I showed you there, you can list the components or you can list the services which are there. So these component types are basically what is enabled in your cluster. So some clusters will have many component types. Some of the cluster will have non-component types. So dependent upon your cluster and its environment, these things will be listed down. So for my instance, I have all the components being installed already into my local MiniShift instance. So that is why it showed me a pop-up mentioning that I can select a Spring Boot, I can select a Node, I can select any other component type. We select latest for the component type version. And now you can see the component Wild West is successfully created. So if you see here, this component is already created. So the next thing is to create a fronted application, which is in Node.js. So we go back to this repository and we just clone the Git, we go to the application, we again do a new component. This time we'll be directly using the Git repository. If this repository already there in our local workspace, I can also use that. But for this demo, we are using Git repository, we paste the URL, we name it Wild West frontend. And there's a Node.js application, the type of the select latest for the component type. And now it asks us, do you want to clone the Git repository for the created component? So for this demo, we will say no. And as soon as the component is getting started, you can see whatever changes which are needed for the push is there on the terminal. So we did not switch to the OpenShift console, go to the application, see the deployment configs and see what builds are running, what are the steps which are being performed. So all the logs can be directly seen on the VS Code terminal and whatever changes we want to do, we can do parallely in the workspace and the build will be running. So whatever deployment is there for the... So now let's wait for the build to finish so that we can link these two components and see the game working. So now you can see this component is created on port this and this is set as an active component. So now as we have two different components here running, let's go ahead and describe this component. So here if you see, there are different scenarios which are listed. So you can describe that component, you can see the logs which are running, you can even create a URL for that, basically creating a route for that component and even making those changes you can push, you can watch and even open that, say if you have a node, just a web interface, simple web interface, you can just directly open that into a browser. So everything basically from a developer perspective is done directly inside this editor and whatever open shift scenarios you need to cover can be done through this. This is basically the front end component. So once we describe that, we can see this is the component is of type node js and this is the git repository source and when we describe the backend component that basically tells us it's a Java component with sources directly taken from the binary file. So whatever information we need for that component or an application can be directly done from the UI itself. So now the next step is to link these two components together. So we go ahead and do link component. So as we all only have one X different components, so the pop-up basically lists us, okay, do we need to link the wild-based backend? So we select this, we want to link this and now we have to select which port are we doing this. So the UI here is pretty smart here so that if you have say multiple services running or multiple components running and if you want to link one component, it will figure out that, okay, which component needs to be linked to that or which service needs to be linked to that so that the developer need not worry, okay, what type of service has to be integrated there. We select port 8080, front end. So now after this, the linking between the back end of the front end is done. Let's move to see how the game basically developed. So now an application in the browser. So for that we need to create a route. So once we go and open that in the browser, VS Code asks us to create the route automatically and it will open the browser. The other way is to directly create a URL from here and then open it in browser. So we'll directly go ahead and open in browser. It asks that there is no route created, should we go ahead and create it? We say yes. Once the route is created, the application will definitely open in the browser and you can see now the front end and the back end are linked and this is the game which loads. Now the user can play this game and click on this. This is how the... So basically this game is basically shooting all those parts or all those routes which you have into a service. So the front end is basically the component which we had and the back end is basically at the meantime creating those routes and meantime whatever service you are getting, killing, those are getting into the back end and being done synchronously. So this basically gives an example that how you can integrate different front end and back end application, do some changes, deploy it in OpenShift within few minutes and everything is up and running directly from your editor. And this basically is the experience which you want to give the developers. All the changes from the OpenShift extension. So the only thing you need to do is just install VS Code, go to the marketplace and install that extension and that's it. And this is for developers who are writing in say, I'm a Java developer and I want to code in Java. It works for me. But if say if someone else is a developer who is very fluent in Node, it works for him the seamless way. And in the future we are also supporting different languages like Go, Ruby, Python. Everything which is out of the box will be supported directly with this extension. So it is nothing specific to a language. It is just specific to whatever the developer prefers and wants to integrate that with the OpenShift instance. So this is it for the demo. If you have any questions, any curiosity for that, let me know. So this is the GitHub link for the Odo tool which we are using at the back end and this is for the link for the marketplace where this is OpenShift connected there. So pretty easy experience which you want to give to the developers because things are changing pretty quickly and everyone wants to integrate things with their OpenShift or Kube clusters. So this is how Red Hat is helping the developers onto that. So, another question, yeah? Yeah, so the question he has is if we make any changes to my backend or say my Java application, how Odo does that and how VS code implement it? So right now your Java component created is basically a component, right? Whatever changes you make to an editor it automatically saves and it automatically does a new push and those push are automatically being done at the back end. So as a developer you need not worry that you need to again get a tar file and again do a deployment. That push will automatically be running at the back end. Yeah, that image has, yeah. Yeah, that image has that capability to whatever changes are there, it looks at the watch and as soon as there are changes it runs a new build and that build again will be integrated to that front end and things will move. Yeah, new push is always there whenever you make some changes at the back end or even at the front end. Yeah, basically that scenario you have say 0.1 jar whenever when you new push that jar is replaced by the new one and that things works. Yeah, so whatever changes there in the backend side for the component side or service side is done by Odo and VS code does integrate that from the developer perspective. So your question is does it support only container-based or you can do a VM-based deployment also on that? So I would say if you have your application or any scenario in your OpenShift cluster if it is running onto that cluster this extension will support that. Yes, yes, thank you.