 And I think point here, okay, so. Yeah, no, I mean. So, hello, hello, what time is it? Hello. Sorry. I don't know. What time is it? Not yet. 53. 53. Hello. Hello, guys, welcome to the session, the last session today. My name is Adrián Moreno, and with me I have Magni Salam. We both are software engineers. We both work for the EMC. So who here has experience with Cloud Foundry? And who has experience deploying Cloud Foundry on top of OpenStack? Okay. So today we are going to talk about how OpenStack integrates with Cloud Foundry. So let me just go through the agenda. So the first thing we're going to do, we're going to just provide a base for the talk. So just talk a little bit about OpenStack, what's it good for. Then we're going to introduce Cloud Foundry. And then we're going to talk about how Cloud Foundry integrates with OpenStack. So these are the main points. And then I'm going to hand it over to Magdi, which is going to give us some cool demos of how that works. And he's also going to give us some real-world challenges that we have faced at the customer sites. And after that, we are going to open up for questions and answers. So before I forget, at the end of the presentation, we are going to make a raffle. So just make sure you don't rush out when we finish. Because you may want to win an awesome prize. So let's get it started. So nowadays, enterprises are looking for a private cloud. There are some offerings out there, some solutions. But if you look at the numbers, if you look at the adoption rate, you look at the maturity level, and you look at the contributions, there is one clear winner, which is all OpenStack. But you guys know that if you take the OpenStack, the open source OpenStack, that's a little bit difficult if you want to deploy that on your own. And that's why so many vendors out there have released their distribution of OpenStack and other vendors like Dell EMC offer their turnkey solution. Actually if you want to take hours, you can just stop by the booth tomorrow because it's too late today. You can stop by tomorrow and take a look at that and have a first impression of our solution. So OpenStack is very good at the infrastructure layer. So you can create spin-up VMs, create volumes, networks, subnets, snapshots, and so on routers and everything. You can even use heat to automate that, to create your infrastructure and automate it. And you can go one step further and you can have Murano, the application catalog in order to deploy apps and services on top of the OpenStack instance. So that is great, but there is a problem. I am a developer. Who else is a developer here? All right. So we as developers, what we want is just to take care of our code, just make it look good, make a great app and push it somewhere and don't worry about what's beneath our application. We don't want to care about what's the infrastructure that our application is running on top of. So apart from that, we also want to follow a DevOps methodology. We want to integrate it with a CI-CD pipeline and, as I said, only worry about our code and not about the infrastructure. So can OpenStack help us right now as it is? So as I said, it's very good at the infrastructure layer. What about for developers? So the answer is yes, but we can use Cloud Foundry to do that. So Cloud Foundry is a platform for developers to push their applications and don't worry about anything else that your application. So Cloud Foundry runs on top of multiple clouds and you can use it as a developer framework, provides application services, and it's actually very convenient for developers to push your applications, deploy applications. You can scale it out, scale it in, depending on your needs, no worrying about anything else. So just to see how easy it is deploying an application in Cloud Foundry, this is a simple example that we have put together. So the first thing you need to do in Cloud Foundry and using the Cloud Foundry CLI is targeting your cloud. So you just say, OK, so Mac Cloud is running on that endpoint and I'm using that space, our organization. Once you do that, you just push your app. So pushing your app means deploying your application. So you have your application code. You need to specify some configuration files so that Cloud Foundry knows what type of application you have and how to deploy it. But once you do that, you push your application, that goes to Cloud Foundry, and that gets deployed and that gets accessible from anywhere. So what we do on the third command line here is creating a service. So let's say your application uses a MySQL or a Poetry or any other third-party service. So you create a service because Cloud Foundry can have a marketplace of services. Like I mentioned, Redis, MySQL, Poetry, so there are a set of services out there. So you create a service and then you bind that service to your application. So that's going to inject some configuration into your app in Cloud Foundry that you need to take from that configuration that you take from Cloud Foundry, you configure your application to talk to your service. So right now we have our applications on Cloud Foundry connected to a third-party service. So let's say our application is becoming very popular. So we're going to scale it out. So it's very easy with Cloud Foundry. You just need to run the scale command, CF scale, the app, and the number of instances that you want to have for that application. You can add a plus sign and the number if you want to increment by that number, your number of instances. And that makes it very convenient for developers and for operators also if you want to automate for example the auto scaling, depending on the workload of your application, it's very convenient and very easy to set it up. So the application that we just pushed, it's on top of this diagram. It's one of the apps that we have on top. And below our application, it's Cloud Foundry and below Cloud Foundry we have the infrastructure layer with a selection of Cloud Providers. We are going to focus on OpenStack today. So as you can see, Cloud Foundry has multiple components. It's fairly complex. So that's why we are not going to go deep into Cloud Foundry today. But we are going to focus on one particular component, which is the one that glues together Cloud Foundry and OpenStack. And that component is Bosch that you can see at the bottom of the Cloud Foundry architecture. So Bosch is a tool chain to release software. You can deploy software with that. You can manage the life cycle of your application or your services. And it's very good, especially for large-scale systems like Cloud Foundry in our case. So Bosch is going to be the one deploying and managing our Cloud Foundry environment. So, but apart from Cloud Foundry, it can also deploy other services like Hadoop, Mesquite. I mean, there is a bunch of other services that Bosch can deploy. And as I said, it works on multiple iOS providers. But we are going to focus today on OpenStack. So here we can see three main components. We see on the left-hand side, we see the Bosch CLI, which is used by an operator. So the operator uses the Bosch CLI that connects to the Bosch instance. So that Bosch instance has a layer, the CPI, which stands for Cloud Provider Interface. And that is the one managing all the infrastructure, depending on what is the Cloud Provider that you are using, OpenStack, AWS, Google, and so on. So when the operator wants to deploy something on using Bosch, so you're going to use the CLI that's going to go to the Bosch instance. And Bosch is going to create and launch as many VMs as we have specified. Those VMs are going to have the Bosch agent inside, which is the one that is going to be in charge of reporting and reporting to the Bosch instance so that we can manage and we can check the health of the system. We can scale it up, scale it down, and run some commands on there. So those VMs that you see in yellow is where Cloud Foundry is going to be deployed and the size of the Cloud Foundry cluster is going to determine the number of applications that we can run and so we can push and advance further parameters. So how do we deploy with Bosch? So in order for us to deploy with Bosch, we need to create a manifest. So that manifest is going to tell Bosch what is the roadmap to deploy that service. It's a demo file like you have seen on so many other services and applications, but it's going to be quite extensive with all the information that Bosch needs to deploy Cloud Foundry. So that includes the number of VMs that it's going to use, the network, the volumes, the flavors of the instances, and so many things that Bosch needs to deploy. So with that, Bosch is going to take that and it's going to create all these VMs and it's going to orchestrate the deployment and it's going to also not only that but also manage the lifecycle of the instances. So in case there is a new version of Cloud Foundry, Bosch is going to be the one upgrading your Cloud Foundry cluster. So how do we deploy Cloud Foundry on top of OpenStack? So as I said, we do it with the manifest, but before that, we need to follow some steps. So the first step is to check that we have all the requirements in our environment, in our OpenStack. So there is a checklist for all the requirements that we need for Cloud Foundry. So for example, we need to create some particular security groups, some flavors. We have to check that we have a DNS service configured correctly. We need to check that we have networks. We can create networks, we can create volumes, we can create instances. So there is a checklist, an extensive checklist that we have to make before applying the manifest so that our environment is healthy and ready to run Cloud Foundry. So when we have that ready, we go to the next step, which is deploying the Bosch instance. So as we saw in the other diagram, that Bosch instance is going to be a VM in OpenStack that is going to orchestrate and deploy all the different VMs and instances and resources for Cloud Foundry. So we do that with Bosch as well. So we create another deployment manifest for the Bosch instance. So when we have that, we have the Bosch instance ready. We can move to the third and final step, which is deploying Cloud Foundry. And we create the manifest that we said before. And when we have that ready, everything configured there, we can just run the command Bosch deploy and that's going to trigger the deployment that the Bosch instance is going to perform. So with that, I'm going to hand it over to Magdi, who is going to show us a cool demo of how this manifest looks like and how to deploy some services with Bosch. Thank you, Adrian. Hello, everyone. Before we start, how many of you used the Bosch command before? Okay. I have a few people here. Okay. I have more here. Okay. So how many of you have a few hours, like two or three hours, so we can do live deployment? So I think we don't have enough time. So for our demo, we're going to connect to live Cloud Foundry in a sense that it's running in our Neutrino rack. You can, it's identical to the one we have here in our booth. But I'm going to connect to our data center. So would you like, first of all, would you like a live demo or would you like it recorded? Let's go with the live, try to see. But if it's a connection drop, we can switch to the video. Okay. Let's take it out of here. I don't know if you're in anything, man. Maybe you have to move it to there. I don't know if I can move it, sir. In this view? In you? Yeah. Yes. Big point enough, can you see in the back? Okay. So the first thing, you know, as you know, I see a lot of people here use Bosch before. When you deploy Cloud Foundry, you have multiple deployment files. So one of the famous commands we can run with Bosch is we can type Bosch deployment. And it will return to us a list of all the deployments. So we have Cloud Foundry deployment, and we have the B matrix and Radus deploy it. And under the Cloud Foundry deployment, it shows us all the different VM or the instance that's running there. So if we need to have more detail about, okay, so this is the second column shows the component. So if we need to see how many Bosch VMs running there, we can just type Bosch VM. And now we're going to get very detailed information about each VM running. And as you see, there's a lot of VMs running there. So if you see, I think it's hard to see, but I'm trying to make it large enough for everyone. But if we go up a little bit, maybe here. So this is our Cloud Foundry and all the VMs running there. We can see the name of the VM here, the IP to connect, and the status running, you know, the zone, and the type of the VM. Another command we can run is, say, I don't need to see all of this, I just need to focus on, say, the Radus, how many VMs running there, if I need just to get there. So I can set my deployment, and I'm trying to go to the location of the deployment. So you run Bosch deployments and you point it to a specific YAML file, deployment manifest. So this, I'm pointing to this one. So if I write Bosch in instant, I should get the list of the Radus in instant only. So this is a cool way to just get in instant. So if you know what you have, you're running Bosch and you're running into problem with Radus alone, instead of trying to scroll up and down for all the VMs that are running, you can just point it to the in instant itself. There is some time, one of my favorite command is, for you guys, I'm sure it's similar, Cloud Check. Now this is our savior, the first thing we try to do when we start running into problem with Bosch or our in instant, we see something is not working correct, we just say, okay, let's check my cloud. So Bosch Cloud Check, or CCK, it will give us a list, it will go, Bosch will go and start scanning the database and try to reach out for all the VMs and try to make sure that each VMs, the agent is responding back, and after it responds back, make sure all the VM is good, it second stab it, you want to start to check the persistent task. So I'm happy, there's no problem found, I'm very happy. So for the people who doesn't use Bosch and didn't use Cloud Foundry before, and they are not familiar with the manifest how it looked like, let's try to cat one of them. And let's do type the first one. So this is our Cloud Foundry manifest, and let's see how big it is, oh, my God, did you see how, usually when you edit it, it's over 50,000 line of code or something like that. So, and also depending on your deployment, are you deploying in high availability or are you just deploying a small one? So this is our just demonstration for what you can do with Bosch to inspect your Cloud Foundry. So go back here. So what's next? Okay, so I don't think any one of us would like to say that I'm trying to type this manifest manually, or try to, so there is some tools out there you can do it, but Bivital actually came up with one of the tools is the Opsi Manager. The Opsi Manager is like a website that where you can go and upload your package there, you can use it to create the manifest there, and it doesn't take much, it just give you some main parameter that depend on your environment, and it will go and create a manifest for you, and it will trigger Bosch to deploy the Cloud Foundry for you. So this is, let's see, I think, so this is our Opsi Manager, and as you see it just you come to the dashboard. When you install it first time, you install the Opsi Manager, it come by default with this one. So the Opsi Manager, that's where Bosch Innocent would be deployed. And if we try to look into the sitting here, take us back to what Adrian was saying, that when you deploy Bosch Innocent, in order to deploy OpenStack on top of Cloud Foundry, you need to make sure that you're innocent and healthy, you have all the prerequisites, and here you start collecting the prerequisites. You need your authentication URL, you need talent information, you need SSH key, and SSL certification. Then I take you, start taking you another step, okay, now we're going to talk about the director itself, and we give more information. And you need, of course, for people who deploy it, you know, deploy it Cloud Foundry before we need SSH endpoint for the blob storage. So we can compile our packages and build back and push it there. You can create network. So as we said, we need information about the infrastructure, we need information you collect about the network, you block the information here, like, okay, here is my OpenStack network, this is ID, this is what is the ID address I'm going to use, and the DNS sends a gateway. So it is a user interface that's easy for us to block information without having to deal with creating the manifest manually. And once we finish, all what we do is just go here and hit Apply Changes. Just setting it, it will create, it will create the ops director for us, and I'm ready to deploy my Cloud Foundry after this. How to do it is using importing product. I can import the pivotal component, like a pivotal elastic runtime, the pivotal matrix, now the ECOLOGY AMX bridge, and this three component is the three main component for Cloud Foundry. After this, I can go and add more component, but in order to the minimum configuration we need to go is we have this three component. So in elastic runtime, you enter some main information, like, okay, this is where my domain were run. So we enter a space name for the system and for the app. You also, we need to configure your high availability. So are you going to use external load balancer or are you going to use just internal load balancer? Or you can use the Omnistack's high availability proxy here. So when you need, you can import your own certification or you can have auto self-sign certification here. Another point here is we can look is actually the database. With pivotal Cloud Foundry, you can use external database or you can use the internal database and it's highly recommended to use it always in high availability mode. So we need a blob storage, here we can give more information that what we need. What we need. This stuff actually is documented very well and pivotal Cloud Foundry documentation. If you go to pivotal docs, it's actually documented with a screenshot. It's actually one with a screenshot, so it's very easy to follow. Another area I need to highlight here is the errant. That's where after you finish the deployment, pivotal try to run a smoke test to make sure that the elastoclun time is running correct and balance and push for your app manager. So the app's manager, it's a user interface. You can see your app there. You can manage your organization and space or you can use Cloud Foundry CLI. Again, say you have everything imported and deployed, so actually when you click apply changes, it creates logs and it keeps track of the logs. So let's just look for some of the logs here that after we deploy it and add it and stuff, so you can see it, look for packages to make sure the packages is compiled and it already exists because as you see it's already compiled and we have stem cells here and it's very detailed. It's always like the end to see that it's actually exit zero or it is a mouse. Sorry. And you left hope for me. Anyway, so let's go back. All right, as you see that we are able to deploy Cloud Foundry in three steps and you have OpenStack, you can get Pivotal, you install it and just create the manifest and have Cloud Foundry in top. So very easy. But is it really easy? I'm not sure what you would think, but you know, we actually deploy Cloud Foundry in our OpenStack environment and production and sometimes we run into some challenges. I don't want to say it's an issue because it's always a challenge and with the right talent you can fix it. So here I'm just going through some of the examples that we saw when we were running. So one of them is, okay, you have your deployment, you deploy your Cloud Foundry and after you install it, it try to run the errand to make sure that the elastic runtime is actually running and stable and suddenly it cannot reach to your end point. So in this case, we found like it's some network issue, make sure there's no firewall issues that blocking you, make sure you're not behind proxy, one of recommendation to set up floating IB for HVM. So maybe you can bypass this issue. This is one of my favour. So how many of you tried to stop the Cloud Foundry before? It's easy, just run BoshStop and stop the whole Cloud. It's easy to be done. There's a challenge. You always, once you do this, you run to try start, BoshStart, and guess what? I got Cessero. So you have the console here, cluster, and it's not able to start. You have the ATCD. It's not able to start. So what's going on here? The R in cluster mode are not able to start. So it's one of the issues and I have the URL here, how to restart the cluster together. You SSH to HVM, there's a command there called month job. You run month job and you just type month job stop the console agent or the ATCD agent. After this, there is a folder for the console data. You remove this folder. You save, you exit, you Bosh deployment again, and the console should start. We have the URL for the workaround. This was an interesting one too. So after I shut down the Cloud Foundry, I tried to restart again and during the start up, suddenly, I started me error. I cannot connect to this VM or error creating the VM. So there's multiple area here you can check because this now is related, you know, if you cannot create the VM, so what's happening in my, my hypervisor or my Cloud. So we go to open the stack and I start checking, all right. First of all, can I create a VM and it's just like a Bosh problem, but I can create it in my own. So if you are able to create it, okay, next step, what kind of hypervisor Bosh hitting? Maybe there's a problem in the hypervisor itself and maybe I take it out of the loop and try again and see what's will happen. Or maybe I'm able to create the VM, but when I try to attach to the presence and disk, I can't attach the volume. So one of the steps here is in our case, for example, it was issues of volume and volume was giving us hard time. So we can log into MySQL for a sender MySQL database and you can update the status of the volumes there and try to detach it from any other NSF. So some troubleshooting. This is what's issue run to when we run Clown Foundry 1.6 or PCF 1.6 is any time I'm trying to add a new tile, I try to upload the new package there. I get error and I have to go back to the Opsi manager and post the certification again. And this issue is fixed in 1.7. So if anyone tried to use older vision, try to stay with Bivitul also always in the most recent version. Okay, this one was interesting too. So this is also documented in Bivitul Clown Foundry website that it's non-issue that if you shut down the Clown Foundry and try to start it, always you have a problem starting MySQL in the cluster mode. And the trick here is you find some one of them is started and the rest is failing one or two starting and one failing. So try to get all of them in the failing mode and just run after this Bosh run, Bosh run error and start up. So there's a last command down there and it will actually fix the cluster for you. We saw this one twice, just picked the wrong size for the Ops manager. And as you add more tiles and try to Bosh mode deployment, we're just running out of memories there and we are no longer able to access the UI. So if you try to access the UI and getting error, you cannot access. So you can go back, check what is the memory utilization in this VM and try to increase it or you can check the ACL rules. So this is just some of the few issues we saw with Clown Foundry and OpenISsec. So what is our condition for you guys? So far, OpenISsec, Clown Foundry, good or bad to each other? So, yeah, it's not perfect yet. So, one of the challenges, if you try to build your own OpenISsec. So, myself, I have my big server and I download some of OpenISsec and use Orchestrator and just deploy it all inside some VMs. That's good for me to play in my server. But if I'm talking about a company enterprise and I try to go for full production, can I just use the same method? Or it's now becoming more complicated process. So I need to find the right talent and hunting for the right talent these days is not easy job. I need to assemble the correct hardware that I make sure that all of it will work actually together. And it's not only about building the OpenISsec. The problem is maintaining after you open. And this is where the catch usually is. So, we have some real life example here that we have a media company. We don't have to mention the name, but this is a true story. They start in 2013 and they build their own OpenISsec. They start having problem during the upgrades. They hired a lot of consulting. And so far, they still suck in Icehouse. One of the other real-time story is this credit agency. They start kicking the project two a year ago and hire Xvert and so far, they still in developing mode. Prototyping actually, so in order to save time, make sure you are able to have a good cloud and you're able to maintain it. We recommend for you VXRAC Neutering System. With VXRAC with new system, we have the hardware. You can deploy OpenISsec with one click, just add surface, and you have OpenISsec deployed for you. And you can using the native hybrid cloud, which is a pivotal cloud funder to run your cloud funder in top of OpenISsec. And you're ready to go and develop application very quick, very easy after you get Neutering System. I encourage everyone of you guys to check our booth. At A1, we have actually the VXRAC sitting there and we can give you a demo and you can see the hardware. It's not a Christmas tree, it's actually the real deal. So I would encourage you to visit us. This is some use cases why we talk about Neutrino. It's a turnkey solution, it's like the iPhone, but for the cloud native application, you can deploy multiple surface there and you will get enterprise support, the AMC support with the hardware. And here's some of the use cases, it's DevOps friendly, you can deploy applications here and Hadoop ends up landing. So if you're planning to have Hadoop in your system, so you get VXRAC to give you OpenISsec, cloud funder and Hadoop. So conclusion, we see OpenISsec, cloud funder, actually they are almost perfect for each other. It's the two biggest open source project we have and two biggest open source community. But like any real life relationship, even if the perfect marriage has problem and sometime people need just try to understand each other. So in order to try to understand each other, you need to have, your cloud operator need to have the correct experience. And the correct experience, you can gain it by, training, trying to error, deploying. And sometime also this experience dependent, are you getting a turnkey solution or you're getting just building in your own and sometime what kind of cloud version or vendor you are using. So that, I hope not any question. So no, no, no, I'd say. So Bosh, Bosh work was VMware. It's a, okay. So the question we have is, is Bosh CCK, is just command for OpenISsec only? And the answer, no, it's one of Bosh command and the Bosh compatible was VMware, EWS and OpenISsec. So it depends, it doesn't matter what is the IIS layer, it can actually run for, once you deploy it, it can run in any one. So you can use it in all of them. Any other question? Rafael, okay. How are you today? Pick one. See who's the winner. So the winner is two, seven, nine. Nobody? Oh, we have a winner here. Awesome. Congratulations. Well, thank you guys for coming. Okay.