 Hello. Good morning, everyone. My name is Julio Colón. I'm from the Dell EMC. I'm here with my co-worker, Lita He, and Magdi Salem. We're going to be talking about Murano. We have an agenda here, so we're going to have a few topics we want to go over Murano. First, a quick review for those of you who have never used Murano. How many of you have heard about Murano? How many of you have it installed? A few hands. Okay. That's going good. How many plans to use? How many plans to use it? Okay. Good. So we are all in the same boat. So I'm going to do a quick review. Just a few seconds there. What are the challenges to doing in Murano? What are the containers? What are containers and how are we using it to help deploy Murano? And then we're going to show you how to deploy an app catalogue. And at the end of the session, we have a Q&A. And just learned we also have some raffle tickets around. We're going to get in at one price for you guys. Okay. So a quick review of Murano. Yeah. So Murano uses a regular component of OpenStack. And as you see here, we have a quick overview of the architecture. And it uses heat, keystone, and horizon. Everybody here, I guess, should know about this. And the reason about Murano is it helps automate some of the deployment of applications. So for that, there's something called a Murano engine who drives mostly other construction. And then there's a Murano API who allows the communication and the interfacing with the engine. Gladly we have a Murano CLI which allows the interfacing with the engine through the API. And there is a Murano dashboard which is used to connect to horizon. And through horizon, it goes through the API and through the engine to do orchestration. There is a Murano engine that is installed to facilitate the VMs and installation. In this diagram, we have two rabbin and queues. We go over that later. It's not necessary, but that's how we have it set up. So what is Murano itself? Murano, when you install it, you will have something like an additional plug-ins added to your horizon. And the whole reason of this is to facilitate through the user interface how to access the app catalog and the environments that you're going to be creating. But in reality, Murano, when you look at it, is like the phones that we had, the flip phones back a few years ago where we used it only for calls. And that was the only use for calls. But then we have an app store. And that makes our life easier. We have apps and we can do things with them. We have Uber or PayPal and all this application that can help bring people together or get things done faster. And the same concept is here with Murano. You have apps that you can download from the web, put it in the marketplace or the Murano front-end, and then you can easily deploy your environment for, like in this case, an Apache server, you click and technically you're done. And if you need a continuous integration system like Jenkins, it will be deployed for you. So you don't really have to do this manually anymore because Murano, just like the app stores, facilitates the deployment. When I started with, when I started coming to the OpenStack summits, I really liked the whole approach of Murano. And then I tried to do installation. And then this was really challenging for me. And based on the survey here, I think everybody really knows what Murano is, but only a few of you have it installed. And I wonder why, right? So the challenges that I run with, which maybe is the same challenges that you're having, is there are many steps to follow in order to get Murano installed. If you look at mostly of the components in OpenStack.org, you will see that there are really detailed instructions on how to install Nova, Neutron, and all these other components. But if you look at Murano, not really nothing, really what written there, that we can follow as the base core packages. So there's also, once you get to the instructions and try to find how to install it, you will have conflict with packages. There's some people in conflict, there's some Python, installing issues. Sometimes the library doesn't work well. And there's some learning curve there. On top of that, there are all the tricky set of areas that we have to work with. We have a local MySQL, you have a local Rabin queue, Keystone integration. You have insecure and SSL connections. If you want to make it secure, there's another overhead there that you need to configure. And then you have to do multiple installations. You have the Murano API, like I showed in the architecture. You have the engine and the end points. And at the end, once you have mostly of the backend instruction done, then you have to fight with the horizon to get it deployed into your UI. So assuming everything works and you get everything in the horizon, then you start having these issues. You're not able to communicate with the API. The errors sometimes are dangerous. So what we love Murano, we really like, and we really like to improve it. Oh, I forgot one slide here. So if you go to the command logs, sometimes you get these errors also which doesn't help you. So we really try. So like I said, we love Murano and we really like to improve it and we like to help people get it going on. It's a great piece of technology. So I was discussing this with my co-workers because we wanted to see, okay, there's got to be a better way that we can help other people get in Murano running. So I talked to my co-worker here, Lita and Maggie, and they decided to do something about it. So this is where I'm going to let Lita here, to explain what did he do to get this better approach. Thank you, Julio. So the goal here is we want to achieve for this exercise is to want to have something that the users can pick it up quickly and start running with it. So to make it easier, so instead of spending all the time to troubleshoot all the issues that Julio talked about, so you can grab something and get it running so it's focused on developing the features instead of pulling your hair to try and figure out why this error message means. And also we want to serve this as some kind of springboard for you to want to further customize your environment and try to build new images, trying to build, deploy in different ways, trying to see what's in there. So it's kind of a very easy starting point to get it started. So you don't have to spend weeks to set it up. That's our goal here. So we kind of choose the Docker container to try this, and there are a few advantages. So for example, the Docker can help you to isolate the dependencies instead of getting all these conflicting dependencies, especially between the people or whatever the pattern package is installed by your native management taxi system and some other Python management system. So the Docker can try to minimize that. And also we can help to kind of automate some of the configurations between different components. And also once you find a good combination and you can save them into the image so that you don't have, you know, next day you wake up and you try to compile and suddenly somebody checked in your code and then your system is broken again. So we're trying to get a stable environment for people to use. So this is kind of like a deployment architecture of what you will get from the container. And you'll see this kind of very similar to the architecture presented by Julio earlier, but in this case we put everything inside this container just for simplicity. And you'll see there's a rapid MQ running which is basically, we can talk about you can deploy multiple to rapid MQs, one is for your infrastructure for OpenStack and another one is for the communication between the agent and the Mirano engine. And also it has the API running, it has the engine running there. And also once the VM is deployed by Mirano, then you start a Mirano engine which will internally will configure your applications and do whatever the things you want to do. And also in addition it has a database down below there and also a horizon with the Mirano dashboard. So what I've seen here is kind of get packed into the single container. Before I go any further, for those who are starting with Docker, this is not the best use of Docker technology, container technology, because in general we want to the container to be micro-service for something as small as possible. And to run quickly, it's definitely that we're using this as for simplicity, we're putting everything inside Docker. This is not the best ways to use it. So for those who are starting with this, don't miss an ad by these packages. So just a word of caution there. So here's some of the prerequisites to get this running. So of course you need to learn Docker a little. It may have some learning code for you in the beginning, but if you have no Docker already, so this should be very straightforward to get started. And of course you would need an open-stack environment. And since we found out that most troublesome issue with the agent is with Mirano deployment is that you want to make sure that your network is configured correctly. Otherwise you would have a lot of trouble deploying your catalog. So one thing we found is to make sure that your internet has access, your network has internet access, especially the DNS server, because once the Mirano agent started in the VM, it's going to go to the internet and pull in all these packages. And if it doesn't, we cannot resolve those names, then you'll be in trouble. So that's where we kind of get hit in the very beginning. So we'll try to figure out why time out. And another thing you want to make sure that the user that running this Mirano application needed to have this heat stack owner role. And otherwise it will fail with the heat in orchestration. Okay, so to get started, we have things that checked into the GitHub and you can certainly kind of pull down that from the GitHub and modify this startup script. And also the GitHub also contains a Docker file. So for those who want to further explore how to expand this to your product environment, then you can change the Docker file and customize. So, but to get it running simply, the minimum you need to do is to configure where is your keystone host and where the username password and where is the admin project. And it will start for you. And those are the few parameters, the minimum parameters that you can start. So if you go through the script, you will see there's a few more things in it with some default configuration, the port numbers, which you can customize to your environment. But for you to get started quickly, this will be something you need to configure. Again, I just want to say this is a little kind of prototype we're doing. And I mentioned about the Docker technology here. Maybe in the future, what we want to do is to have a Docker compose to replace this clunky startup script. But there's something, if we get time, we may do it to make it even easier and more kind of a modern application that you could deploy. And just quickly, once you have that started, you will just run this startup script. And you will see at the bottom of this slide here, you will see it has some output. And then you can tell the log file there. You can also certainly change where the log file goes, things like that. And in the end, you should print out this URL to get to the Mirano dashboard. And once you get it up and running, so this is what it will look like. And I'm not going to go through a lot of details with these steps here, because they're a very good quick start document from the Mirano project page. But here, once you get it running, you'll see on the left, you'll see a Mirano tab with application catalog and some of the how to manage the packages. So the first thing you need to do once you start it, you need to kind of import a package. A package, basically, instead of a zip file, a zip file contains some of the various components that are needed to run the application. And my colleague, Mike D, is going to cover that in more detail later. And the next thing you need to go over is to create an environment. An environment in Mirano is kind of defined as a group of isolated services. And they generally are not supported in the fair with each other. And also for security reasons, they generally deploy a environment in a particular network segment. So here, if you look at this environment before now where we are choosing the network where we kind of configured earlier, you can just choose that. You can also choose to create a new one. So that's kind of you create an environment like this. Once your environment is ready, what you do is just to add a component to the environment. Here, the little Apache HTTP component is whatever you uploaded with the package earlier. And this should be very straightforward to go in. The next is to deploy. Very simple. Just go ahead and deploy. And shortly after, you will see go to your instance page on horizon. You will see the VM guys spin up. And under this cover, all this thing is just done by heat orchestration. So you can view some... If you are into the heat templates, and you can take a look of the templates on this screen here. And voila. So if everything works, that's what you would get with that page. So that basically... You should be happy once you see that page. And that means you have an end-to-end process completed with... Hopefully in a few minutes. Okay. So here's some of the... Again, you can also use the Mirana CLI. You can get into the Docker engine. For those who are not familiar with Docker, you can learn those command quickly. So you can also create a UMA file to point to where this open stack is. And then, you know, I'll give you an example here. You can do the Mirana list. There's a long list of command lines you can run. But, you know, you can usually get into the container and run this command to explore. So here are some of the troubleshooting things we have encountered. Once you deploy the containers, you should have this log files in the directory over there on the container host. And also, you can also SSH to your VM and also check... On the VAL log, there's a Mirana agent log file. You can check log. Also, the resolve.conf, which should have your DNS server that you configured earlier for the network. And another thing is the Mirana agent.conf, which is basically the RabbitMQ configuration. Those things are there in place. And if they are not there, then that means there's something wrong, either with your image or with the process of deploying these things. And here are some of the common issues we run into that, of course, you know, people make mistakes by getting the password wrong. For that, you can check the Mirana that you need a log file to show you something that, you know, you get it wrong. And also, there might be your environment because you might need to communicate with RabbitMQ on your open stack deployment. So your corporate file may block the port, so you have to make sure that those ports are open. And also, we'll talk earlier about the DNS server configuring for the subnet. So if your application is not developing for example, Apache is not running on that machine, double check your DNS configuration. And also, we found out that there's some, you know, normally we run this on the VMware environment and some open-stack environment, there's version machines, there's some time-skills. So you have some big time-skills between your container host and also the open-stack environment. Then you may run into something like this and like a funny thing like this, which is very hard to debug. So it's just in case you run into that. And I think that's what my portion of the presentation I will pass the rest of the presentation to my colleague, Meghdi. Thank you, leader. So we're going to talk about the app catalog. So how many of you build the Marano application and submit it as an expert? So what is the app catalog? So Marano provides us a symbol web interface that's integrated with Horizon. So the Cloud operator doesn't need to go to a different place. They're just inside the Horizon website. They can go to Marano catalog and you will have all your applications sitting there. And the application catalog is a great area where you can group part of your application and just assign it to one environment. So if you have your web developer, he needs his website, his database, his queue. You can all of them group them, assign them to environment, and just with one button, you have all the environment deployed for you. So how we can create a Marano application? Creating a Marano application is actually a very simple process. You create the application, you import it into Marano, then you deploy it. So let's see how this happens. Marano application has a specific structure. So, and usually when you import it into, when you create the application and import it into Marano, you have to import it in a form of compressed file, it's a format, symbol, it's in format. So here we can see the structure of the application. The first we have, we need to have a classes folder. That's where you will have your Marano programming language, the PL classes. That's very much its YAM file with all the structures here. Then we have the results folder. The results folder will have the deployment and execution plan. Also, it has deployment scripts here. You need to create a UI folder and that's where the user when they import the package and that's allow the end user when they execute the application or deploy it, it will give them this UI with different field to create the application. Then we have the application entry points, the main manifest for the application and we have the logo. So if we try to look behind the scene, that would be very much something very simple like this. So as I said before, we can interact with Marano, we're just executing the container. Then after this, here we have example of the classes. It has a YAM file for Nixon. We have the resources folder there with the files and the UI and the logo and we'll just run as a command. So if you finish the steps, the next one is we try to import the application into the catalog. So if we try to do it from the command line here, first make sure that we have the Keystone resources loaded. Sometimes we forget to try to run the command right away. After we load the resource file, we can just run a simple command Marano back to import and we specify our application. If everything works well, we should see this application and its logo showing under Marano catalog. And if we choose to import it, it's the same thing, we can give it a name, we can give it a different name of which side and the UI here is the UI file here. It shows how we, different fields we specify in the UI file and we can just simply choose to deploy this application. So you have the application, you assign it to an environment. Once it's added to the environment, like as we see here, this environment has the component Nixon. We just click in deploy environment and if we check under innocent, we should see as an instant there and if we try to access from the website, we should see it there. So that's our hello world with Marano running in container and something to mention at the end that Marano in order to deploy it doesn't use any image. It should use a specific glance image that it need to have Marano Asian running data and that's how Marano services communicate with the agent. So here we have some steps how you can clone it from GitHub and the last thing here at the end, the disk image that how you create your image. Now if you try to check GitHub for Marano, there is tons of applications there. So I encourage you to go and look, I actually have quite a bit of libraries there. So you can download the application and customize it based on your company need if you need to change something there or if it's good for your business, you can just deploy it as it is. That's more information about the container and our hello world example and that's it. That's why I have a few guys and we have one more. One more? We don't have the queue. So we have raffle and before the raffle, do you have any questions? I don't want to question from you. Questions? Questions? Raffle. If you have no question then we are going to go into the raffle. You got a question? You can run it anywhere you have the Docker engine stored, right? This is for prototype and not for production environment. So in general, if you have, depending on really how you deploy your open stack, if you are running on bare metals, you probably should have what this Marano engine, the APIs, just as you deploy it like Nova, they will have engine APIs, whatever they're saying, the databases. You can share the databases. For production, you would definitely want to move this component to your best practice instead of, you know, this is definitely not for production, it's for, you know. Got a question? There's a microphone now. Can you talk to the microphone? Hello, I want to clarify what kind of changes you experienced while trying to install Rano for example from packages, because as far as I know, Rano is following the same requirement suggestions as the rest of the open stack components, so they use the same requirements, I believe, and from perspective of packaging because I am doing packages. As RPMs are as devs, they are known as the same and they are working out of the box. So I'm just curious what kind of experience you had. So normally, in a proper environment, you could have an open stack running already, so you don't have to worry about, you know, here's what I can use. Another thing is that, is my speaker on? Yeah, we can hear you. So is that, so you normally have your environment, another thing is that if you normally pull some packages like Redhead, the pack stack, whatever, you run it and set it up, it's already running in half an hour, so you have those things previewed already for you, but for us, we're trying to add in Rano, then we have to Google those packages ourselves, because somebody did hard work already for other components, but for Rano, we haven't seen a lot of people doing that. I think maybe Marantis has done some good in, but for us, we want to do some prototype and to feed our environment, we have to go through the packaging systems, we have this different environment. But the idea is that you're deploying Rano on already deployed open stack. Right, right. We don't distro you use, right? And if the distro doesn't contain Rano as a service, then probably you have issues with deploying it. Right, exactly. So we, this past release cycle, we concentrated on addition of Rano into Ubuntu Cloud Archive packages, RDO packages, and upstream open stack packaging program. So now it should be there in all of these distros. Oh, that's excellent. You guys did a great job, and this is actually very useful. I think that you might want to use, publish your Rano Docker on Docker Hub, for example, right? Actually, there's an automated build that's on Docker Hub. You can, when you run the script, it's pull down that image automatically, and you run it. So you don't need to build the Docker on yourself, the image yourself. Thank you guys. And as developers also, it's a really quick environment for us to set up and build applications, right? That's actually part of my question. Have you considered pushing this to the upstream documentation and making this one of the default ways for people to try Rano and like pushing that to Rano? Yeah, that would be a good idea, but so I think one of the things we ran into is that it's highly, the environment we set it up, highly dependent on if we were running on Ubuntu 14.04, and there's some packages that are kind of a little bit old. Yeah, right, right. So what we would like to do next would be, I mentioned earlier, using Docker compose to make it more like a Docker, more than Docker application, instead of clunky everything in the container, which is a bad way to use the container technology. So we want to do that, and maybe we can think about just publishing that to the document. That's definitely a good idea. I definitely invite you to, from the Rano side, I definitely invite you to come. Well, I'd like to see that on the official Rano documentation. Yeah, yeah, sure. I think that's the way forward. Great, great. We'll think about it, and that's a good idea. I maybe have just a tiny bit of a command that, in the past two cycles, I think in the Okata and Newton, we already can, in Newton, what was the previous? In Midica and Newton, I think in Midica already, you can just, if the VM has the access to the internet, it won't pull the Rano agent from the, from pip, so you don't really need to build it, to build the specific images, but still, that's actually great. That's awesome. Thank you. Thank you. Thanks. All right. Rafa? Yeah, let's go. Where is Rafa? Yep. How many we have? One, one. Just one? Just one. All right. The number is 121. Uno, dos, uno. Come on, check it out. Not here? Try again? One, two, one, okay. Going once? Going twice? Going once? Going twice? Okay, let's try the next one. All right. Number nine? Nine. Oh, wow. There you go. All right. All right, give him one. Okay. All right. All right. That's how I press me for today. Thank you for being here and thank you for your time. All right. Have a nice day. Here we go.