deb-murano/doc/source/appdev-guide/use_cases.rst

Use-cases

Performing application interconnections

Murano can handle application interconnections installed on virtual machines. The decision of how to combine applications is made by the author of an application.

To illustrate the way such interconnection can be configured, let’s analyze the mechanisms applied in WordPress application, which uses MySql.

MySql is a very popular database and can be used in quite a number of various applications. Instead of the creation of a database inside definition of the WordPress application, it calls the methods from the MySQL class. At the same time MySQL remains an independent application.

MySql has a number of methods:

• deploy
• createDatabase
• createUser
• assignUser
• getConnectionString

In the com.example.WordPress class definition the database property is a contact for the com.example.databases.MySql class. So, the database configuration methods can be called with the parameters passed by the user in the main method:

- $.database.createDatabase($.dbName)
- $.database.createUser($.dbUser, $.dbPassword)
- $.database.assignUser($.dbUser, $.dbName)

Any other methods of any other class can be invoked the same way to make the proposal application installation algorithm clear and constructive. Also, it allows not to duplicate the code in new applications.

Using application already installed on the image

Suppose you have everything already prepared on image. And you want to share this image with others. This problem can be solved in several ways.

Let's use the HDPSandbox application to illustrate how this can be done with Murano.

Note

An image may not contain murano-agent at all.

Prepare an application package of the structure:

|_  Classes
|    |_  HDPSandbox.yaml
|
|_  UI
|    |_  ui.yaml
|
|_  logo.png

Note

The Resources folder is not included in the package since the image contains everything that user expects. So no extra instructions are needed to be executed on murano-agent.

UI is provided for specifying the application name, which is used for the application recognition in logging. And what is more, it contains the image name as a deployment instruction template (object model) in the Application section:

Application:
?:
  type: com.example.HDPSandbox
name: $.appConfiguration.name
instance:
  ?:
    type: io.murano.resources.LinuxMuranoInstance
  name: generateHostname($.instanceConfiguration.unitNamingPattern, 1)
  flavor: $.instanceConfiguration.flavor
  image: 'hdp-sandbox'
  assignFloatingIp: true

Moreover, the unsupported flavors can be specified here, so that the user can select only from the valid ones. Provide the requirements in the corresponding section to do this:

requirements:
  min_disk: 50          (Gb)
  min_memory_mb: 4096   (Mb)
  min_vcpus: 1

After the UI form creation, and the HDPSandbox application deployment, the VM with the predefined image is spawned. Such type of applications may interact with regular applications. Thus, if you have an image with Puppet, you can call the deploy method of the Puppet application and then puppet manifests or any shell scripts on the freshly spawned VM.

The presence of the logo.png should never be underestimated, since it helps to make your application recognizable among other applications included in the catalog.

Interacting with non-OpenStack services

This section tells about the interaction between an application and any non-OpenStack services, that have an API.

External load-balancer

Suppose, you have powerful load-balancer on a real server. And you want to run the application on an OpenStack VM. Murano can set up new applications to be managed by that external load-balancer (LB). Let’s go into more details.

To implement this case the following apps are used:

• LbApp: its class methods call LB API
• WebApp: runs on the real LB

Several instances of WebApp are deployed with each of them calling two methods:

- $.loadBalancer.createPool()
- $.loadBalancer.addMember($instance)
# where $.loadBalancer is an instance of the LbApp class

The first method creates a pool and associates it with a virtual server. This happens once only. The second one registers a member in the newly created pool.

It is also possible to perform other modifications to the LB configuration, which are only restricted by the LB API functionality.

So, you need to specify the maximum instance number in the UI form related to the WebApp application. All of them are subsequently added to the LB pool. After the deployment, the LB virtual IP, by which an application is accessible, is displayed.

Configuring Network Access for VMs

By default, each VM instance deployed by io.murano.resources.Instance class or its descendants joins an environment's default network. This network gets created when the Environment is deployed for the first time, a subnet is created in it and is uplinked to a router which is detected automatically based on its name.

This behavior may be overridden in two different ways.

Using existing network as environment's default

This option is available for users when they create a new environment in the Dashboard. A dropdown control is displayed next to the input field prompting for the name of environment. By default this control provides to create a new network, but the user may opt to choose some already existing network to be the default for the environment being created. If the network has more than one subnet, the list will include all the available options with their CIDRs shown. The selected network will be used as environment's default, so no new network will be created.

Note

Murano does not check the configuration or topology of the network selected this way. It is up to the user to ensure that the network is uplinked to some external network via a router - otherwise the murano engine will not be able to communicate with the agents on the deployed VMs. If the Applications being deployed require internet connectivity it is up to the user to ensure that this net provides it, than DNS nameservers are set and accessible etc.

Modifying the App UI to prompt user for network

The application package may be designed to ask user about the network they want to use for the VMs deployed by this particular application. This allows to override the default environment's network setting regardless of its value.

To do this, application developer has to include a network field into the Dynamic UI definition of the app. The value returned by this field is a tuple of network_id and a subnet_id. This values may be passed as the input properties for io.murano.resources.ExistingNeutronNetwork object which may be in its turn passed to an instance of io.murano.resources.Instance as its network configuration.

The UI definition may look like this:

Templates:
  customJoinNet:
    - ?:
        type: io.murano.resources.ExistingNeutronNetwork
      internalNetworkName: $.instanceConfiguration.network[0]
      internalSubnetworkName: $.instanceConfiguration.network[1]
Application:
  ?:
    type: com.example.someApplicationName
  instance:
    ?:
      type: io.murano.resources.LinuxMuranoInstance
    networks:
      useEnvironmentNetwork: $.instanceConfiguration.network[0]=null
      useFlatNetwork: false
      customNetworks: switch($.instanceConfiguration.network[0], $=null=>list(), $!=null=>$customJoinNet)
Forms:
  - instanceConfiguration:
      fields:
        - name: network
          type: network
          label: Network
          description: Select a network to join. 'Auto' corresponds to a default environment's network.
          required: false
          murano_networks: translate

For more details on the Dynamic UI its controls and templates please refer to its specification <DynamicUISpec>.