 Thank you everyone. The title of this session is, it's the best way to deploy your application on OpenStack. Time has come, so let's get started. First of all, let us introduce ourselves. I'm Hidekatsu Nakamura. I have experience with creating web application for seven years. From SX, started to work with OpenStack as operator. Committed some parties through docs. I'm contributing to Murano project from Nittaka Cycle as a developer. He is Shu Muto. I'm Shu Muto, a web developer. I had customized SX and For some Horizon with our customer. Started to contribute to Horizon and dashboard plugins since last September. And now, our Magnum UI core reviewer and internationalization liaison for Magnum UI. This is a outline of this session. At first, we explain purpose of this session and we define actors for deploying application. After that, we explain each projects which may be used to deploy application on OpenStack. Grounds, Groudinit, Heat, Murano, community app catalog. For each project, we explain project outline, present cons for deploying application, show suite of applications. Finally, we summarize this session. Why we are here. I happen to attend community app catalog session at Tokyo Summit and have some questions. Why community app catalog treat free packaging? Nono packages, heat templates, gross images. Nono itself is application catalog service. Community means what? Third, there are other projects which deploy application such as SRAM, what's the difference? So, we are going to talk about which application is suitable for these services. We support these four actors need to deploy applications. First, application developer. They develop applications. Second, application distributor. They package and distribute applications that are developed by developers. Third, application operator. They get application from distributor and deploy them. Fourth, application user. They use application become available by operators. So, first week, we explain Grounds. Grounds is image service for managing virtual machine images and its metadata. User create virtual machine images and upload them. Community provides a guide how to obtain, create, and modify virtual machine images. Virtual machine image can be shared between projects. Virtual machine image is usually categorized by OSFAST. But application's point of view, application can be included in the image. So, what is Grounds for the actors? What the actor should do? Application distributor creates the image that includes applications. Application operator registers the image and don't have an instance from the image. Application user uses the application installed in the instance. The pros and cons are derived from the fact that the image includes the application beforehand. The advantages of using Grounds are, first, deploy speed. Application user can use the application in a very short time. Second, deploy reliability. Application is installed in the image, so application is certainly installed. On the other hand, these advantages, configure application is not possible in advance. For example, you cannot configure with a name or password before boot. This can be a security risk. As a result, application which has no need to configure for starting news is suitable for Grounds. For example, desktop applications such as deployment environment, editor, calculator, clock, auto viewer are suitable for Grounds. So next is cloud init. So what is cloud init? Cloud init is Python scripts. It handles early initialization of a cloud instance. For example, set local, set hostname, copy SSH public key, install and update packages. Use puppet, Chef server. Cloud init is not OpenStack project, but open source project. And cloud init is pre-installed in most cloud image. Cloud init can execute files which is sent from outside when booting. So what is cloud init for the actors? And what the actors should do? Application distributor creates an image that includes cloud init and configure it. Officially, most cloud init includes it. And configure is a feature. Application operator registers image and launch instance from the image. Application user uses application installed in the instance. So the advantages of using cloud init is unique configuration for each instance. Cloud init is installed in the image and can configure each instance according to each instance environment. On the other hand, disadvantages of using cloud init are first, only one instance configuration is possible. Second, configuration timing is limited. Cloud init works only when booting. Third, depending on the environment, it may be difficult to confirm status or to analyze errors. Since you need to see the output of Nova console log or directly see file inside of the instance. As a result, application which is enough for one instance and need to configure is suitable cloud init. For example, agent, agent for monitoring some resources in the instance or client of client server type software or small scale application for private use. Next is heat. Heat is template-based orchestration service for primarily managing infrastructure by executing appropriate OpenStack API codes. Template allows creation of most OpenStack resource types. Template is text file, which are readable and writeable by humans and can be managed by version control tools. Heat is well integrated with software configuration management tools such as Puppet, Ansible, and Chef. Software deployment resource type applies software configuration to one instance. Software config store software configuration, Shell script, Puppet, Ansible, and Chef. Nova server resource type means virtual machine instance. Software deployment resource type associates a config resource with one instance. Software configuration can be written in the template directly or can include a file by cat file function. But it's not enough for some cases. I'm Ansible fan, so I wanted to apply playbooks based on Ansible based practices, electric structure. Based practices creates role, group variable for each environment. I wanted to use that structure. Ansible playbook searches, roles, group bars, first bars, et cetera, from the directory it exists. So I must copy the playbook directory to the directory includes automatically generated playbook. But since this example is for image created by disk image builder specifying Ubuntu OS, the placement of playbook may be different. Anyway, this is fairly tricky, I think. I hope, smart way. So what's the heat for the actors, what the actors should do? Application distributor creates template files or creates software configuration files. Application operator gets the template files and run or gets a software configuration files, create template files, merge them and run. It's a template and run, heat finds a difference and executed. So that is the advantage of using heat in the following. Most open stack resources can be used by using serometer resource types, or scaling application can be achieved. Appet, Ansible and Chef are integrated. Application configuration without changing your resources. By writing your own resource plugins, you can use external services. On the other hand, the disadvantage of using heat in the following, application distributor or operator have to study how to write template files. But heat template language is declarative and writing with fairly easy. Application operator have to manage template files by their own tool. And as I said, using Ansible with rules. Group plus is, sorry, to use Ansible with rules needs tricky way. As a result, application which need to use various open stack resources is suitable for heat. Open stack resource types are, for example, neutral load balancer services, serometer, truth, truth is database as a service. Et cetera. Or large scale application, which is free country needs to scale up or down your resources. For example, data analyzer or search engine, I think. Next project is Rano. Rano provides UI and API to easily compose, deploy, run applications, and manage their life cycle, including instances. Even users are familiar with cloud environments choose from the available applications with intuitive UI. At first glance, you cannot take your eyes off web UI, but run power is beyond UI. Run application package structure is a following. Run application package is archived as GIF file. GIF file includes manifest file. Manifest file is an entry point for each run application. And it's very similar to the manifest of the archive. GIF file includes a picture used in the catalog. UI directory contains YAML file. Dynamically creates UI. Classes directory contains YAML files. Application class definition written in Rano programming language. This includes on instance creating security groups. Resource directory contains scripts directory. Script directory contains all scripts.sqt file required for an application deployment. And YAML file that describes the install process of application on the virtual machine. Rano programming language class is a core of Rano application. So, Rano programming language is represented by YAML and YACO. YACO stands for yet another query language. Rano programming language is object-oriented language. Rano PL class is a YAML dictionary with predefined key names. Example is shown on the right side. Instance, network, and security group are defined as class. Hot template is dynamically created and executed for creating infrastructure. Rano is application first. Rano defines application class for reusing. And this is WordPress example. WordPress class is defined on the left side. When deploying WordPress, instantiate a batch HTTP server class and call deploy method. So, application deployment. Tenant manages applications in the environment. Once Tenant deploys environment, the network subnet and router are created automatically. Network is customizable. So, Rano use case, application distributor creates Rano application packages and approaches them to Rano. Application operator selects application from UI or CLI and deploy it. So, pros and cons. The advantages of using Rano is the following. First, Rano provides means of creating application catalog UI. Second, as I explained, application is defined as a piece of component as class. Rano has plugin architecture. So, by creating plugin, application can connect to external services. Glass image and heat hot template can be packaged. So, you can manage glass image heat template as application. On the other hand, disadvantages of using Rano are first, since there are few documents, study Rano is deep learning curve and Rano programming language is actually programming language. Bugs are inevitable. So, which application is suitable for Rano? Systems composed of various applications is suitable for Rano. Various applications are, for example, web server, application server, memory cache, database, name, monitoring agent, identity provider, job management. Next is committee app catalog. Committee app catalog is committee-driven application catalog. Containing glass image, heat templates and Rano application package. Committee app catalogs website is appsopenstack.org. Horizon plugin is also available. So, use case, application distributor publishes glass images, heat templates or Rano application packages to the public location. It's shown in the website and dashboard. Application operator, browse it and select glass images, heat templates or Rano application packages from public website. Copy the name or URL to your open stack environment and deploy it. Use a can directly deploy through dashboard. So, browse and go on. Advantages of using committee app catalog is unified catalog of applications across glance, heat and Rano. These advantages are to publish applications, change source code of committee app catalog. Committee app catalog is not for private applications. And internet connect is a must. So, which applications suitable for committee app catalog? Basically, applications open to the public. It's suitable for committee app catalog. For example, test image developer want to use. Second, sample application. Third, commercial software to be advertised. So, conclusion. We saw four projects. But there are missing features. Some features are accomplished by integrating with other projects or writing programs. First, unified application catalog for both public and private. Second, application management. Data protection, monitoring, alert, metering. SMARG project application data protection as a service is targeting data protection. Monitoring, alert and metering may be achieved by Celerometer or Monasca. Depending on your environment. Third is development support. Test continuous integration. Integration with developing tools such as Eclipse. Integration with version control system. In terms of development support, SMARG is targeting from application characteristics by summarize project selection process. If application needs only one instance and need no configuration with grants, if need to configure grants plus cloud need. If application needs several instances, heat or Murano. If application is fairly simple or uses various open start projects, use heat. If not, use Murano. If you want application to open to the public, use communication catalog. That's all. Thank you. Any questions or comment? Several of your projects listed as a Khan study cost. Could you explain what that means? Okay, several pages. Study cost. Okay. This is a slide of heat, heat study cost. This, about heat? Ah, I see. We have to study mainly how to write template of heat template, hot template or mainly hot template. About Murano, how to packaging G5 or writing Murano programming language. I think mainly Murano programming language. Murano programming language, there are few documents now, so they steep learning curve. Any other questions? So, what idea is going to be used to execute whatever is passed through? Pardon? Sorry. Cloud init, are they executed as root or are they executed as a user specified by the implementation? The question was when cloud init runs, are things executed as the user or as root? The answer is that cloud init runs after root, because it basically happens early enough in the bootstrap process before anything else exists. Ah, you mean cloud init is executed by root or user? Which is? What user will be explained? Okay. That's all, thank you.