 So hello everyone for coming to our talk. Hope that you saw many good ones in this summit and hope that this is a good one before we end the summit. So my name is Tin and this is AK and today we're going to talk about boss UI and you're probably wondering who are they now. So after you have seen our refreshing faces, hopefully you can jump on. So who actually are we? So we are software engineers as you can look at our attire and we are from Delhi MC Dojo. We have been Cloud Foundry contributors for more than three years and we have worked and delivered talks on multiple talks like blockchain as a service, GPU as a service and then Cloud Foundry on Kubernetes and persistence in Cloud Foundry. But why are we here today? So today we're going to talk about what is boss again and what make it amazing, the pain-poise of it. Then we're going to introduce boss UI, some future work and some questions and answers. Yeah, we're hoping that the slides will be so good that you don't have any questions. We'll see. Yeah. So what is boss AK? I thought you know everything about boss. In the initial times, I did not know. But how many of you know, wash or have been using Bosch for some time? Okay, assuming this talk was about Bosch UI, I expected that some people will be there. But as a first time user, whenever you start using Bosch, you need to search it. So when we search in Google for Bosch, we get this. It's a great series and great reviews. I haven't seen it, but I recommend it all of you watch it. But if I keep digging more, I get this maybe. And when I'm looking for manifest, I'm not looking for the manifest of a washing machine or screwdriver. I'm looking for the manifest of my cloud foundry Bosch, which is actually why we needed more details. So well, Bosch can be, I mean, segregated into three terms. You can say that it does life cycle management or different VMs so that it can protect the VMs and keep it moving. Or it can do the infrastructure orchestration so that whether you are using AWS or GCP or OpenStack or vSphere, you can still have the same interface of using Bosch in different environments. So Bosch has CPIs for all these infrastructures so that it can continue using it. It also has configurations. So you can configure your VMs or your deployments as much as you like. And with so many options we have all out there. So well, that's something about Bosch. So what else? So I saw on the market now, there's many other guys doing this like puppet ansible and what's the difference? Yeah, so this is a slide from Altarose back in 2015. So I actually met the person who created this slide yesterday. So he's in this CF summit. And it shows how Bosch is able to do all the things which all the other tools were not able to do back in 2015. Like puppet, chef and ansible, they were not able to orchestrate or deploy the life cycle management. And even though now they have improved their capabilities and puppet and ansible can do much more than what is represented here. But so has Bosch and its own deployments. Bosch can do much more. We concur with this slide that Bosch is much more powerful than all the other tools out there. And it gets better. So it seems like we have no reason to be here. But after working with Bosch for three years, I would like to point out some of the pain points of using Bosch that we have accumulated. For example... Hold on, I thought you said that this is just Bosch deploy manifest dot yml. That's all we do for Bosch. Yeah, it's actually that simple. When you have the manifest, you just run this command and then you can have something in your data center. But the devil in the details is that manifest itself. Every time you want to construct a manifest, let's take an example of the CF deployment manifest. Right. So you have like 1500 lines of code. This is an example of it. And this is just like two instances. And it already have like 30 or 40 different properties. And each of the properties can affect the success or failure of the entire deployment. So it really takes advanced skill developer or dev ops to be able to manage this manifest, not for entry level. So it's very high learning curve and it's very easy to make mistake. And every time you make mistake, you have to redeploy everything and it takes 20 or 30 minutes again. Which is very frustrating. So the question is how can we make it easier for the community to adopt Bosch? Because we want to drive Bosch forward. So my answer for it is very simple. In the end, we want that easy deploy button for all the open source projects in the cloud factory community. So done. Yeah, that's a good dream. How do you do it? Yeah, the way we do it is Bosch UI. Did that answer your question? Before going into Bosch UI, let's talk about how actually Bosch works. So in a very simple model, this is how Bosch does everything which it does. So it has three steps. You have to deploy the Bosch director. You have to prepare the manifest which will contain all the details of the VMs or the deployments you need to do to the Bosch director. And then the Bosch director takes that manifest and deploys the whole thing in your infrastructure. If you go into a bit more details, in order to deploy the Bosch director, you either have to create new credentials in the YML file, or you have to retrieve those old credentials which you use to deploy it again when you have made a mistake or something like that. And then for creating that manifest to create the whole deployment, you again have to create the whole manifest from scratch, or you can edit or manipulate the existing manifest based on the issues or problems which you have seen in the existing deployment. Yeah, so you are an expert, so I don't see any problem with doing this. Yeah, so the problem is when we actually start doing it. Because every time we make these manifest in the YML files, we make some mistakes which we always do because we are humans. And when we make these mistakes, we have to go back to our YML files and again edit or check out what we have done. And when we go to lunch and we come back hoping that it is deployed, it hasn't deployed and we again look at the YML. Or we added a space or something else which makes you think that maybe JSON is better than YML. Yeah, so do you have a solution for this? Yeah, so whatever we are seeing right now, we can probably remap in a way so that it can get easier to do that. So it's simple. Whatever we have shown the three steps, we can actually create interfaces for all these three steps so that we don't have to worry about what we might have done before or what we are going to do later to affect what we are trying to do. So if we create interfaces for all these, we can probably have a better solution. Yeah, so I got you now. So I just have to build something called Boss UI, which means so this model will become something abstract like this when I have interface for step one, interface for step two and three. Yeah, hold on. So this means that whatever YML files we had is now in the UI fields. So instead of YML files, now I have to just fill all those UI fields like thousands of fields after fields. That's your solution? Yeah, where's the easy deploy button? Yeah, where is it? So we actually rethink about this model one more time and we think about where's the easy deploy button and where can we put it? Can we do more in the step two? Like, for example, when I look into Docker or when I look into IntelliJ, I see something like Docker half having their images or IntelliJ that have their extension, right? So how about we have an open source marketplace for like the open source manifest out there for concourse, cloud factory, half a million or something like that. And so actually we build a little marketplace for the Boss UI and we build a Boss UI using Spring and React. And what do you use Spring and React? Because I like it. Actually, because we're thinking about maybe we're going to use it on Windows or macOS and seem like Java Spring is a good option. And maybe later on the technology can change. But for now, we go with that model. So let me just start the... So at first we just start this Boss UI application and then I'll just go into localhost 8080. It takes some time to start off. Yeah, so let me stop there for a second. This is step one. This is step that you just enter your Boss Director credentials. And then you're going to deploy it in, for example, vSphere. So I check all the credentials. I hide it here so that none of you know it. And then it's actually on the right side, you see that it's calling the BossGrate end just like in the back end. But in the front end, you won't see anything except this is actually initializing. You can go to lunch or take a cup of coffee or something because this one take a long time. But I'm going to skip forward. And after deploying the director, it actually say running here. And then it update the cloud config with all these information. And now it's the second step. The second step is I go to the marketplace and then just take whatever deployment I want to do. So I just click on that plus button for the deployment. Right now I have four of them concourse. Have a minial and jumpbox. And today I feel like I want to deploy a jumpbox. So I just click deploy. Yeah. So as you can see here, let me start for a second. So it will upload all the releases. And then after finishing, it will start the last task is the deploy task. And then, yeah, then I just want to verify if task six is running. And let me go to that. So I just do task six. Yeah, I make a lot of typing mistake there. So you can see that it's created a missing VM. And after that, it's going to update the VM just like normal boss command. But in the front end, you don't know anything. You just know that you have to wait. And it will success eventually. And now I have a jumpbox running in my data center. So the last step is I just go inside the jumpbox, make sure that it's running. Nothing special here. Yeah, so even though it's not a live demo, but we make mistakes so that it looks like a live demo. Yeah. So the cool thing about this. Yeah, so we actually use this tool for our own concourse to we manage our own concourse and menu clusters for in our vSphere environment by this tool. And we have a short demo. It's a smaller demo just to show. So if you look at it, we have these jumpbox concourse and menu already running in our Cambridge vSphere environment. And we were trying here to deploy the harbor instance. So that we can use harbor now. Fortunately, unfortunately, this failed because the manifest wasn't correct. But the point is that if you have all the open source manifest ready and ready to be used, we can actually have all that one button. I mean, one click deploy for all these marketplaces. Yeah. So what is there for the future now? So the future, there's a lot of room to grow for this project that we are doing. So one of the things that we think is like a plug-in model for like after you deploy concourse, you can see on the right side the concourse dashboard or something. And so it's like extra step for all of the for the user to see in the front end. And also we can improve the performance by including more native API, which means that we can have the boss create and update cloud config. We write that in Java, for example, to tweak the performance. Yeah. So that's the presentation. If you have any questions, you can ask us now. Yeah. No questions, right? Okay. Is there a way of actually entering configuration information so that you get to manifest, but you have to modify it before you can deploy something? Yes. So later on, we think about in the marketplace, you can have form for like some, if you want to modify it, then you can edit it. But for now, we just like taking all the default. For example, the VM type is default. The everything is default so that you can easily just click one deploy button. Yeah. So the purpose for this was to use, let the community start using Bosch more easily, rather than worrying about all the manifest and everything to go into the details. So they can just one click and start using. Yeah. So, so more like for entry level developer, because every time I introduce it to my friend, they're like, oh, I have to configure this manifest. Can I just like deploy cloud factory? And yeah, so any more questions? It's nice project. There's also a project called Bosch UI, which was initiated by Stark N1. And it's more oriented toward after when it's, when it's deployed and you want to see the state. Yes. And they are for next steps. I don't know if you miss ID. I guess not. But it's usually useful for day two to see the current state of a Bosch deployment. Things like credit secrets and Bosch links. I know there's a new API to see Bosch links. And this is something which is missing when you are, when you have large deployment to be able to visualize. So that's for D2. It's not for initial experience, but. Yeah. So, so you, you wonder what's the difference between these two tools or you think it's more like for the future work? Probably it's a way of converging in the same tool of the initial experience, which is nice. But also for the two having something graphical, which we miss. Yeah. So we looked at that project and we saw that it actually, we need to just deploy the Bosch director first. And then with that director, we can use the UI, which will give us all the details of the Bosch deployments. Yeah. It's actually, so it's more like for managing each of the VMs. But our intention is like, you don't even need to worry about the VMs and you just like looking at the deployment itself. But I'm not, I'm not sure, but maybe we can integrate that project into. Yeah. Any more questions? Okay. Thank you for. Thank you.