Kategorie: technology

Develop Cloud Applications for OpenStack on Murano, Day 4: The application, part 2: Creating the Murano App

The post Develop Cloud Applications for OpenStack on Murano, Day 4: The application, part 2: Creating the Murano App appeared first on Mirantis | The Pure Play OpenStack Company.
So far in this series, we’ve explained what Murano is, created an OpenStack cluster with Murano, and built the main script that will install our application. Now it&8217;s time to actually package PloneServerApp up for Murano.
In this series, we&8217;re looking at a very basic example, and we&8217;ll tell you all you need to make it work, but there are some great tutorials and references that describe this process (and more) in detail.  You can find them in the official Murano documentation:

Murano package structure
Create Murano application step-by-step
Murano Programming Language Reference

So before we move on, let&8217;s just distill that down to the basics.
What we&8217;re ultimately trying to do
When we&8217;re all finished, what we want is basically a *.zip file structured in a way that Murano expects, with files that provide all of the information that it needs. There&8217;s nothing really magical about this process, it&8217;s just a matter of creating the various resources.  In general, the structure of a Murano application looks something like this:
..
|_  Classes
|   |_  PloneServer.yaml
|
|_  Resources
|   |_  scripts
|       |_ runPloneDeploy.sh
|   |_  DeployPloneServer.template
|
|_  UI
|   |_  ui.yaml
|
|_  logo.png
|
|_  manifest.yaml
Obviously the filenames (and content!) will depend on your specific application, but you get the idea. (If you&8217;d like to see the finished version of this application, you can get it from GitHub.)
When we&8217;ve assembled all of these pieces, we&8217;ll zip them up and they&8217;ll be ready to import into Murano.
Let&8217;s take a look at the individual pieces.
The individual files in a Murano package
Each of the individual files we&8217;re working with is basically just a text file.
The Manifest file
The manifest.yaml file contains the main application’s information. For our PloneServerApp, that means the following:
1. #  Plone uses GPL version 2 as its license. As of summer 2009, there are
2. #  no active plans to upgrade to GPL version 3.
3. #  You may obtain a copy of the License at
4. #
5. #       http://www.gnu.org
6. #
7.
8. Format: 1.3
9. Type: Application
10. FullName: org.openstack.apps.plone.PloneServer
11. Name: Plone CMS
12. Description: |
13. The Ultimate Open Source Enterprise CMS.
14. The Plone CMS is one of the most secure
15. website systems available. This installer
16. lets you deploy Plone in standalone mode.
17. Requires Ubuntu 14.04 image with
18. preinstalled murano-agent.
19. Author: ‘Evgeniy Mashkin’
20. Tags: [CMS, WCM]
21. Classes:
22. org.openstack.apps.plone.PloneServer: PloneServer.yaml
Let’s start at Line 8:
Format: 1.3
The versioning of the manifest format is directly connected with YAQL and the version of Murano itself. See the short description of format versions and choose the format version according to the OpenStack release you going to develop your application for. In our case, we&8217;re using Mirantis OpenStack 9.0, which is built on the Mitaka OpenStack release, so I chose the 1.3 version that corresponds to Mitaka.
Now let’s move to Line 10:
FullName: org.openstack.apps.plone.PloneServer
Here you&8217;re adding a fully qualified name for your application, including the namespace if your choice.
IMPORTANT: Don&8217;t use the io.murano namespace for your apps; it&8217;s being used for the Murano Core Library.
Lines 11 through 20 show the Name, Description, Author and Tags, which will be shown in the UI:
Name: Plone CMS

Description: |
The Ultimate Open Source Enterprise CMS.
The Plone CMS is one of the most secure
website systems available. This installer
lets you deploy Plone in standalone mode.
Requires Ubuntu 14.04 image with
preinstalled murano-agent.
Author: ‘Evgeniy Mashkin’
Tags: [CMS, WCM]
Finally, on lines 21 and 22, you&8217;ll point to your application class file (which we&8217;ll build later). This file should be in the Classes directory of the package.
Classes:
org.openstack.apps.plone.PloneServer: PloneServer.yaml
Make sure to double check all of your references, filenames, and whitespaces as errors with these can cause errors when you upload your application package to Murano.
Execution Plan Template
The execution plan template — DeployPloneServer.template &8212; describes the installation process of the Plone Server on a virtual machine and contains instructions to the murano-agent on what should be executed to deploy the application. Essentially, it tells Murano how to handle the runPloneDeploy.sh script we created yesterday.
Here&8217;s the DeployPloneServer.template listing for our PloneServerApp:
1. #  Plone uses GPL version 2 as its license. As of summer 2009, there are
2. #  no active plans to upgrade to GPL version 3.
3. #  You may obtain a copy of the License at
4. #
5. #       http://www.gnu.org
6. #
7. FormatVersion: 2.0.0
8. Version: 1.0.0
9. Name: Deploy Plone
10. Parameters:
11.  pathname: $pathname
12.  password: $password
13.  port: $port
14. Body: |
15.  return ploneDeploy(‘{0} {1} {2}’.format(args.pathname, args.password, args.port)).stdout
16. Scripts:
17.  ploneDeploy:
18.    Type: Application
19.    Version: 1.0.0
20.    EntryPoint: runPloneDeploy.sh
21.    Files: []
22.    Options:
23.      captureStdout: true
24.      captureStderr: true
Starting with lines 12 through 15, you can see that we&8217;re defining our parameters – the installation path, administrative password, and TCP port. Just as we added them on the command line yesterday, we need to tell Murano to ask the user for them.
Parameters:
 pathname: $pathname
 password: $password
 port: $port
In the Body section we have a string that describes the Python statement to execute, and how it will be executed by the Murano agent on the virtual machine:
Body: |
return ploneDeploy(‘{0} {1} {2}’.format(args.pathname, args.password, args.port)).stdout
Scripts defined in the Scripts section are invoked from here, so, we need to keep the order of arguments consistent with the runPloneDeploy.sh script that we developed yesterday.
Also, double check all filenames, whitespaces, and brackets. Mistakes here can cause the Murano agent to experience errors when it tries to run our installation script. If you do experience errors in this case, after  an error has occurred, connect to the spawned VM via SSH and check the runPloneDeploy.log file we added for just this purpose.
Dynamic UI form definition
In order for the user to be able to add parameters such as the administrative password, we need to make sure that the user interface is set up correctly.  We do this with the UI.yaml file, which contains the UI forms description that will be shown to users and tells users where they can set available installation options. The ui.yaml file for our PloneServerApp reads as follows:
1. #  Plone uses GPL version 2 as its license. As of summer 2009, there are
2. #  no active plans to upgrade to GPL version 3.
3. #  You may obtain a copy of the License at
4. #
5. #       http://www.gnu.org
6. #
7. Version: 2.3
8. Application:
9.  ?:
10.    type: org.openstack.apps.plone.PloneServer
11.  pathname: $.appConfiguration.pathname
12.  password: $.appConfiguration.password
13.  port: $.appConfiguration.port
14.  instance:
15.    ?:
16.      type: io.murano.resources.LinuxMuranoInstance
17.    name: generateHostname($.instanceConfiguration.unitNamingPattern, 1)
18.    flavor: $.instanceConfiguration.flavor
19.    image: $.instanceConfiguration.osImage
20.    keyname: $.instanceConfiguration.keyPair
21.    availabilityZone: $.instanceConfiguration.availabilityZone
22.    assignFloatingIp: $.appConfiguration.assignFloatingIP
23. Forms:
24.  – appConfiguration:
25.      fields:
26.        – name: license
27.          type: string
28.          description: GPL License, Version 2
29.          hidden: true
30.          required: false
31.        – name: pathname
32.          type: string
33.          label: Installation pathname
34.          required: false
35.          initial: ‘/opt/plone/’
36.          description: >-
37.            Use to specify the top-level path for installation.
38.        – name: password
39.          type: string
40.          label: Admin password
41.          required: false
42.          initial: ‘admin’
43.          description: >-
44.            Enter administrative password for Plone.
45.        – name: port
46.          type: string
47.          label: Port
48.          required: false
49.          initial: ‘8080’
50.          description: >-
51.            Specify the port that Plone will listen to
52.            on available network interfaces.
53.        – name: assignFloatingIP
54.          type: boolean
55.          label: Assign Floating IP
56.          description: >-
57.             Select to true to assign floating IP automatically.
58.          initial: false
59.          required: false
60.        – name: dcInstances
61.          type: integer
62.          hidden: true
63.          initial: 1
64.  – instanceConfiguration:
65,      fields:
66.        – name: title
67.          type: string
68.          required: false
69.          hidden: true
70.          description: Specify some instance parameters on which the application would be created
71.        – name: flavor
72.          type: flavor
73.          label: Instance flavor
74.          description: >-
75.            Select registered in Openstack flavor. Consider that
76.            application performance depends on this parameter
77.          requirements:
78.            min_vcpus: 1
79.            min_memory_mb: 256
80.          required: false
81.        – name: minrequirements
82.          type: string
83.          label: Minumum requirements
84.          description: |
85.            – Minimum 256 MB RAM and 512 MB of swap space per Plone site
86.            – Minimum 512 MB hard disk space
87.          hidden: true
88.          required: false
89.        – name: recrequirements
90.          type: string
91.          label: Recommended
92.          description: |
93.            – 2 GB or more RAM per Plone site
94.            – 40 GB or more hard disk space
95.          hidden: true
96.          required: false
97.        – name: osImage
98.          type: image
99.          imageType: linux
100.          label: Instance image
101.          description: >-
102.            Select a valid image for the application. The image
103.            should already be prepared and registered in Glance
104.        – name: keyPair
105.          type: keypair
106.          label: Key Pair
107.          description: >-
108.            Select the Key Pair to control access to instances. You can login to
109.            instances using this KeyPair after the deployment of application.
110.          required: false
111.        – name: availabilityZone
112.          type: azone
113.          label: Availability zone
114.          description: Select availability zone where the application would be installed.
115.          required: false
116.        – name: unitNamingPattern
117.          type: string
118.          label: Instance Naming Pattern
119.          required: false
120.          maxLength: 64
121.          regexpValidator: ‘^[a-zA-z][-_w]*$’
122.          errorMessages:
123.            invalid: Just letters, numbers, underscores and hyphens are allowed.
124.          helpText: Just letters, numbers, underscores and hyphens are allowed.
125.          description: >-
126.            Specify a string, that will be used in instance hostname.
127.            Just A-Z, a-z, 0-9, dash and underline are allowed.
This is a pretty long file, but it&8217;s not as complicated as it looks.
Starting at line 8:
Version: 2.3
The format version for the UI definition is optional and its default value is the latest supported version. If you want to use your application with one of the previous versions you may need to set the version field explicitly.
Moving down the file, we basically have two UI forms: appConfiguration and instanceConfiguration.
Each form contains list of parameters that will be present on it. We place all of the parameters related to our Plone Server application on the appConfiguration form, including the path, password and TCP Port. This will then be sent to the Murano agent to invoke the runPloneDeploy.sh script:
       – name: pathname
         type: string
         label: Installation pathname
         required: false
         initial: ‘/opt/plone/’
         description: >-
           Use to specify the top-level path for installation.
       – name: password
         type: string
         label: Admin password
         required: false
         initial: ‘admin’
         description: >-
           Enter administrative password for Plone.
       – name: port
         type: string
         label: Port
         required: false
         initial: ‘8080’
         description: >-
           Specify the port that Plone will listen to
           on available network interfaces.
For each parameter we also set initial values that will be used as defaults.
On the instanceConfiguration form, we’ll place all of the parameters related to instances that will be spawned during deployment. We need to set hardware limitations, such as minimum hardware requirements, in the requirements section:
       – name: flavor
         type: flavor
         label: Instance flavor
         description: >-
           Select registered in Openstack flavor. Consider that
           application performance depends on this parameter
         requirements:
           min_vcpus: 1
           min_memory_mb: 256
         required: false
Also, we need to add notices for users about minimum and recommended Plone hardware requirements on the UI form:
       – name: minrequirements
         type: string
         label: Minumum requirements
         description: |
           – Minimum 256 MB RAM and 512 MB of swap space per Plone site
           – Minimum 512 MB hard disk space
         hidden: true
         required: false
       – name: recrequirements
         type: string
         label: Recommended
         description: |
           – 2 GB or more RAM per Plone site
           – 40 GB or more hard disk space
Murano PL Class Definition
Perhaps the most complicated part of the application is the class definition.  Contained in PloneServer.yaml, it describes the methods the Murano agent must be able to execute in order to manage the application. In this case, the application class looks like this:
1. #  Plone uses GPL version 2 as its license. As of summer 2009, there are
2. #  no active plans to upgrade to GPL version 3.
3. #  You may obtain a copy of the License at
4. #
5. #       http://www.gnu.org
6. #
7. Namespaces:
8.  =: org.openstack.apps.plone
9.  std: io.murano
10.  res: io.murano.resources
11.  sys: io.murano.system
12. Name: PloneServer
13. Extends: std:Application
14. Properties:
15.  instance:
16.    Contract: $.class(res:Instance).notNull()
17.  pathname:
18.    Contract: $.string()
19.  password:
20.    Contract: $.string()
21.  port:
22.    Contract: $.string()
23. Methods:
24.  .init:
25.    Body:
26.      – $._environment: $.find(std:Environment).require()
27.  deploy:
28.    Body:
29.      – If: not $.getAttr(deployed, false)
30.        Then:
31.          – $._environment.reporter.report($this, ‘Creating VM for Plone Server.’)
32.          – $securityGroupIngress:
33.            – ToPort: 80
34.              FromPort: 80
35.              IpProtocol: tcp
36.              External: true
37.            – ToPort: 443
38.              FromPort: 443
39.              IpProtocol: tcp
40.              External: true
41.            – ToPort: $.port
42.              FromPort: $.port
43.              IpProtocol: tcp
44.              External: true
45.          – $._environment.securityGroupManager.addGroupIngress($securityGroupIngress)
46.          – $.instance.deploy()
47.          – $resources: new(sys:Resources)
48.          – $template: $resources.yaml(‘DeployPloneServer.template’).bind(dict(
49.                pathname => $.pathname,
50.                password => $.password,
51.                port => $.port
52.              ))
53.          – $._environment.reporter.report($this, ‘Instance is created. Deploying Plone’)
54.          – $.instance.agent.call($template, $resources)
55.          – $._environment.reporter.report($this, ‘Plone Server is installed.’)
56.          – If: $.instance.assignFloatingIp
57.            Then:
58.              – $host: $.instance.floatingIpAddress
59.            Else:
60.              – $host: $.instance.ipAddresses.first()
61.          – $._environment.reporter.report($this, format(‘Plone Server is available at http://{0}:{1}’, $host, $.port))
62.          – $.setAttr(deployed, true)
First we set the namespaces and class name, then define the parameters we&8217;ll be using later. We can then move into methods.
Besides the standard init method, our PloneServer class has one main method &8211; deploy. It sets up instances of spawning and configuration. The deploy method performs the following tasks:

It configures a security group and opens the TCP port 80, SSH port and our custom TCP port (as determined by the user):
         – $securityGroupIngress:
           – ToPort: 80
             FromPort: 80
             IpProtocol: tcp
             External: true
           – ToPort: 443
             FromPort: 443
             IpProtocol: tcp
             External: true
           – ToPort: $.port
             FromPort: $.port
             IpProtocol: tcp
             External: true
       -$._environment.securityGroupManager.addGroupIngress($securityGroupIngress)

It initiates the spawning of a new virtual machine:
        – $.instance.deploy()

It creates a Resources object, then loads the execution plan template (in the Resources directory) into it, updating the plan with parameters taken from the user:
         – $resources: new(sys:Resources)
         – $template: $resources.yaml(‘DeployPloneServer.template’).bind(dict(
               pathname => $.pathname,
               password => $.password,
               port => $.port
             ))

It sends the ready-to-execute-plan to the murano agent:
         – $.instance.agent.call($template, $resources)

Lastly, it assigns a floating IP  to the newly spawned machine, if it was chosen:
         – If: $.instance.assignFloatingIp
           Then:
             – $host: $.instance.floatingIpAddress
           Else:
             – $host: $.instance.ipAddresses.first()

Before we move on, just a few words about floating IPs &8211; I will provide you with the key points from Piotr Siwczak’s article  “Configuring Floating IP addresses for Networking in OpenStack Public and Private Clouds”:
“The floating IP mechanism, besides exposing instances directly to the Internet, gives cloud users some flexibility. Having “grabbed” a floating IP from a pool, they can shuffle them (i.e., detach and attach them to different instances on the fly) thus facilitating new code releases and system upgrades. For sysadmins it poses a potential security risk, as the underlying mechanism (iptables) functions in a complicated way and lacks proper monitoring from the OpenStack side.”
Be aware that OpenStack is rapidly changing and some article’s statements may become obsolete, but the point is that there are advantages and disadvantages of using floating IPs.
Image File
In order to use OpenStack, you generally need an image to serve as the template for VMs you spawn. In some cases, those images will already be part of your cloud, but if not, you can specify them in the image.lst file. When you mention any image in this file and put it in your package, the image will be uploaded to your Cloud automatically. When importing images from the image.lst file, the client simply searches for a file with the same name as the name attribute of the image in the images directory of the package.  
An image file is optional, but to make sure your Murano App works you need to point any image with a pre-installed Murano agent. In our case it is Ubuntu 14.04 with a preinstalled Murano agent:
Images:
– Name: ‘ubuntu-14.04-m-agent.qcow2′
 Hash: ‘393d4f2a7446ab9804fc96f98b3c9ba1′
 Meta:
   title: ‘Ubuntu 14.04 x64 (pre-installed murano-agent)’
   type: ‘linux’
 DiskFormat: qcow2
 ContainerFormat: bare
Application Logo
The logo.png file is a preview image that will be visible to users in the application catalog. Having a logo file is optional, but for now, let’s choose this one:

Create a Package
Finally, now that all the files are ready go to our package files directory (where the manifest.yaml file is placed) we can create a .zip package:
$ zip -r org.openstack.apps.plone.PloneServer.zip *
Tomorrow we&8217;ll wrap up by showing you how to add your new package to the Murano application catalog.
The post Develop Cloud Applications for OpenStack on Murano, Day 4: The application, part 2: Creating the Murano App appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis

Using the CloudForms Topology View

When working with complex provider environments with many objects, the topology widget in Red Hat CloudForms can be extremely useful to quickly view and categorize information. The topology view provides the ability to view a container provider’s objects plus their details, such as the properties, status, and relationships to other objects on the provider. The topology view is also quite useful for showing cross-links between objects — all of which can be very difficult to visualize when only viewing an object’s summary page.

First introduced in CloudForms 4.0, the topology view was previously available only for containers providers. As of CloudForms 4.1, the topology view can also be used for network providers for viewing objects such as cloud subnets, floating IPs, and network routers:

In addition to topology view for network providers, CloudForms 4.1 also adds a search bar so that objects can be easily searched by name.
The topology view for containers is accessed through the Compute menu, by navigating from Compute > Containers > Topology. The network providers topology is accessed from Networks > Topology. In addition, you can access the topology view from the provider summary screen by clicking the icon in the Topology section.

Simplifying details with the Topology View
First of all, the topology view allows you to simplify information.
In the example below, the OpenShift Enterprise environment comprises multiple objects. It can be difficult to track down specific information, for example the OpenShift nodes. The topology view can assist in sorting out the objects to focus only on the relevant ones.

To view only the nodes, click each object except for Nodes in the top bar to toggle their display off. When the display is off for these objects, they appear greyed out. As a result, in the next screenshot, all you see are the container provider’s nodes:

Alternatively, you can also rearrange the topology diagram by dragging the objects into a manageable layout. For example, if you want to isolate one node and see its relationships, click on the node and pull it to one side of the topology map.
The following screenshot shows one node isolated from the rest, so you can easily see its relationships:

Searching with the Topology View
To make finding objects even simpler, Red Hat CloudForms 4.1 adds a search bar to the topology widget to allow you to search for an object by name. Search a name, and any unrelated objects are greyed out, so that only the objects you’ve searched for are highlighted.
In the following example, a search for the name “ruby-hello-world” reveals a container and a service by that name:

Note that you must cancel the search by clicking the X button before running your next search.
Identifying Relationships with the Topology View
Let’s say you wanted to find out which cloud network provider your floating IPs were attached to. Your network provider setup is fairly complicated, with many cross-linked relationships:

To make viewing your floating IPs much easier, hide the objects you aren’t interested in by clicking them on the top menu bar —  in this case, hide everything but Floating IPs and Cloud Networks.
As a result, you can easily see that 10 of your floating IPs are attached to the cloud network on the left, 7 floating IPs are attached to the cloud network on the right, and one floating IP is not attached to any cloud network. If you want more details on which cloud network is connected to 10 floating IPs and which is connected to 7 floating IPs, you could find out more details by either hovering over the cloud network icons or double clicking on the icon to open a summary page. Right clicking on the icon brings up a dialog with additional actions you can perform on the item.

Troubleshooting with the Topology View
The topology view is also very useful for identifying objects that are not functioning properly, along with errors. Objects that are active and running correctly are displayed with a green outline, where objects with problems are outlined in red, and a grey outline signifies an unknown status. Let’s look at this containers topology example again:

This image shows four non-functional nodes. After identifying these nodes, you can find more information by either:

Hovering over the node: This will show the the object’s name, type (node), and its status.
Double-clicking on a node: This opens a summary page listing the node’s properties, labels, relationships, conditions, and Smart Management tags.
Toggling the Display Names checkbox: This shows all displayed objects’ names.

You can then quickly narrow down where there may be a problem, and troubleshoot from there.
For more information about working with these provider types, see the Red Hat CloudForms 4.1 Managing Providers guide:

For containers providers – see Chapter 5. Containers Providers
For network providers &8211; see Chapter 4. Network Providers

Quelle: CloudForms

Weather Company Data Service helps developers build smarter, more precise apps

Weather patterns are constantly changing. It’s frustrating to not have the umbrella at just the right time or the right jacket when a cold front comes through while you’re at work or were looking forward to an outdoor picnic when a storm rolls through.
Inconsistency in weather can wreak even greater havoc on businesses. In 2014 alone, the U.S. economy lost nearly $50 billion in sales and 76,000 jobs because of weather, CNBC reported.
The good news is that it’s becoming easier than ever to build apps that can help to mitigate this damage. These apps give businesses the intelligence to more accurately plan for and predict for weather changes which can impact everything from sales to customer satisfaction. Recently, IBM launched The Weather Company Data Service on the Bluemix cloud platform. The service gives developers easier, instant access to APIs that provide extended forecast data, geo-specific weather intelligence and highly dependable information.

Using Bluemix to rapidly pull broad and accurate weather data streams into their apps, developers can now build the most predictive and smartest apps for industries in which weather is a concern. They can help predict a storm’s potential impact on consumer behavior or fluctuations in crop prices.
These new APIs are built on recent IBM acquisition The Weather Company’s data platform, as well as the previously available Insights for Weather service on Bluemix. They increase the access that developers have to extended forecasts — up to 48 hours — as well as new intra-day forecasts of up to 10 days, international weather alerts, geo-coding services, and daily and monthly almanac intelligence.
This intelligence and the ability that cloud provides to easily build with these APIs means that almost every industry can benefit from working weather knowledge into its operations. For example, in the aviation industry, weather data can help airlines improve the efficiency and performance of flights, from alerting them to turbulent air patterns to planning for fuel consumption and airport congestion.
In retail, these same insights can be used for a variety of planning strategies. They can help retailers optimize inventory based on weather-triggered purchase patterns, such as stocking more sweaters for an upcoming cold front, or better plan for staffing needs, perhaps increasing the number of sales associates when nice weather is likely to bump up foot traffic.
With these new capabilities on IBM Cloud, developers now have the ability to build into their apps a real-time forecast data grid which is 100 times more precise than publicly available sources, down to a 500-square-meter resolution. They can also tie into governmental alert headlines and details, as well as the world&8217;s most accurate meteorological models from The Weather Company.
To get started with the service, check out The Weather Company Data Service for IBM Bluemix catalog, or watch an overview video on the Bluemix Developers’ Community blog.
The post Weather Company Data Service helps developers build smarter, more precise apps appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

How to Develop Cloud Applications for OpenStack using Murano, Part 2: Creating the Development Environment

The post How to Develop Cloud Applications for OpenStack using Murano, Part 2: Creating the Development Environment appeared first on Mirantis | The Pure Play OpenStack Company.
In part 1 of this series, we talked about what Murano is, and why you’d want to use it as a platform for developing end user applications. Now in part 2 we&8217;ll help you get set up for doing the actual development,.
All that you need to develop your Murano App is:

A text editor to edit source code. There is no special IDE required; a plain text editor will do.
OpenStack with Murano. You will, of course, want to test your Murano App, so you&8217;ll need an environment in which to run it.

Since there&8217;s no special setup for the text editor, let&8217;s move on to getting a functional OpenStack cluster with Murano.
Where to find OpenStack Murano
If you don&8217;t already have access to a cloud with Murano deployed, that&8217;ll be your first task.  (You&8217;ll know Murano is available if you see an “Application” tab in Horizon.)
There are two possible ways to deploy OpenStack and Murano:

You can Install vanilla OpenStack (raw upstream code) using the DevStack scripts, but you&8217;ll need to do some manual configuration for Murano. If you want to take this route, you can find out how to install DevStack with Murano here.
You can take the easy way out and use one of the ready-to-use commercial distros that come with Murano to install OpenStack.

If this is your first time, I recommend that you start with one of the ready-to-use commercial OpenStack distros, for several reasons:

A distro is more stable and has fewer bugs, so you won’t waste your time on OpenStack deployment troubleshooting.
A distro will let you see how a correctly configured OpenStack cloud should look.
A distro doesn’t require a deep dive into OpenStack deployment, which means you can fully concentrate on developing your Murano App.

I recommend that you install the Mirantis OpenStack distro (MOS) because deploying Murano with  it can’t be more simple; you just need to click on one checkbox before deploying OpenStack and that’s all. (You can choose any other commercial distro, but the most of them are not able to install Murano in an automatic way. You can find out how to install Murano manually on an already deployed OpenStack Cloud here.)
Deploying OpenStack with Murano
You can get all of the details about Mirantis OpenStack in the Official Mirantis OpenStack Documentation, but here are the basic steps. You can follow them on Windows, Mac, or Linux; in my case, I&8217;m using a laptop running Mac OS X with 8GB RAM; we&8217;ll create virtual machines rather than trying to cobble together multiple pieces of hardware:

If you don&8217;t already have it installed, download and install Oracle VirtualBox. In this tutorial we’ll use VirtualBox 5.1.2 for OS X (VirtualBox-5.1.2-108956-OSX.dmg).
Download and install the Oracle VM VirtualBox Extension Pack. (Make sure you use the right download for your version of VirtualBox. In my case, that meansOracle_VM_VirtualBox_Extension_Pack-5.1.2-108956.vbox-extpack.)
Download the Mirantis OpenStack image.
Download the Mirantis OpenStack VirtualBox Scripts..
Unzip the script archive and copy the Mirantis OpenStack .ISO image to thevirtualbox/iso folder.
You can optionally edit config.sh if you want to set up a custom password or edit network settings. There are a lot of detailed comments, so it will not be a problem to configure your main parameters.
From the command line, launch the launch.sh script.
Unless you&8217;ve changed your configuration, when the scripts finish you’ll have one Fuel Master Node VM and three slave VMs running in VirtualBox.

Next we&8217;ll create the actual OpenStack cluster itself.
Creating the OpenStack cluster
At this point we&8217;ve installed Fuel, but we haven&8217;t actually deployed the OpenStack cluster itself. To do that, follow these steps:

Point your browser to http://10.20.0.2:8000/ and log in as an administrator using “admin” as your password (or the address and credentials you added in configure.sh).

Once you’ve logged into Fuel Master Node it lets you deploy the OpenStack Cloud and you can begin to explore it.

Click New OpenStack Environment.

Choose a name for your OpenStack Cloud and click Next:

Don’t change anything on the Compute tab, just click Next:

Don’t change anything on the Networking Setup tab, just click Next:

Don’t change anything on the Storage Backends tab, just click Next:

On the Additional Services tab tick the “Install Murano” checkbox and click Next:

On the Finish tab click Create:

From here you&8217;ll see the cluster&8217;s Dashboard.  Click Add Nodes.

Here you can see that the launch script automatically created three VirtualBox VMs, and that Fuel has automatically discovered them:

The next step is to assign roles to your nodes. In this tutorial you need at least two nodes:

The Controller Node – This node manages all of the operations within an OpenStack environment and provides an external API.
The Compute Node &8211; This node provides processing resources to accommodate virtual machine workloads and it creates, manages and terminates VM instances. The VMs, or instances, that you create in Murano run on the compute nodes.
Assign a controller role to a node with 2GB RAM.

 Click Apply Changes and follow the same steps to add a 1 GB compute node. The last node will not be needed in our case, so you can remove it and give more hardware resources to other nodes later if you like.
Leave all of the other settings at their default values, but before you deploy, you will want to check your networking to make sure everything is configured properly.  (Fuel configures networking automatically, but it&8217;s always good to check.)  Click the Networks tab, then Connectivity Check in the left-hand pane. Click Verify Networks and wait a few moments.

Go to the Dashboard tab and click Deploy Changes to deploy your OpenStack Cloud.

When Fuel has finished you can login into the Horizon UI, http://172.16.0.3/horizon by default, or you can click the link on the Dashboard tab. (You also can go to the Health Check tab and run tests to ensure that your OpenStack Cloud was deployed properly.)

Log into Horizon using the credentials admin/admin (unless you changed them in the Fuel Settings tab).

As you can see by the Applications tab at the bottom of the left-hand pane, the Murano Application Catalog has been installed.
Tomorrow we&8217;ll talk about creating an application you can deploy with it.
The post How to Develop Cloud Applications for OpenStack using Murano, Part 2: Creating the Development Environment appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis