ARIA in Practical Use

Admins work with ARIA TOSCA at the command line; the most important actions are therefore console commands. The default working directory is ~/.aria, which you can change by editing the ARIA_WORKDIR environmental variable. The generic syntax is

aria <options> <commands> <arguments>

As usual, you can discover the program version with the --version option. If you want to reset the environment after various modifications, simply use the aria reset command, which removes all installed plugins, service templates, logfiles, and so on from the working directory.

The plugin command executes all plugin-specific commands, in particular for installation and verification. A valid plugin uses Wagon [3] and is saved as a Wagon or ZIP file. To install a plugin, enter:

aria plugins <options> <plugin path>

You can retrieve the list of installed extensions with aria plugins list. Before using a plugin, you should check its validity with the validate command (e.g., aria plugins validate).

Another important task is managing templates. You can create your own cloud service archive (CSAR) files from the template sources. To output details of the templates and then validate a loaded template, use

$ aria service_templates show <template-name>
$ aria service_templates validate <template-name>

You can control the execution of ARIA with the executions command; for example, to start a workflow, enter:

$ aria executions start <workflow-name>

You can manage logfiles with the aria logs command. Targeted logfile output for specific processes is also possible, but first you need to output the IDs of the actions and then query specific information:

aria logs list
aria logs list <ID>

OpenStack Interaction

ARIA TOSCA, in conjunction with Cloudify [4], the most advanced TOSCA implementation to date, can automate and manage heterogeneous cloud environments (Figure 2). OpenStack installations can also be controlled with a special adapter.

Figure 2: Cloudify shows ARIA TOSCA how to do it: Its Blueprint Composer supports the dynamic creation of YAML files by drag and drop.

ARIA supports IaaS integration through the Cloudify context adapter, which allows the execution of arbitrary Cloudify plugins with ARIA TOSCA. Install the adapter with:

$ git clone https://github.com/cloudify-cosmo/aria-extension-cloudify
$ pip install -r aria-extension-cloudify/requirements.txt
$ pip install aria-extension-cloudify

The next step is to install the OpenStack plugin [5]. ARIA supports the installation of extensions in WGN format. The installation of the plugin on the ARIA side is simple:

$ aria plugins install <Wagon_file_path>

Everything is then ready for a first sample file. Here, too, the execution of the Hello World example [6] is a good idea. However, the sample file requires some input: Create a file named inputs.yaml:

external_network_name: extern
webserver_port: 8080
private_key_path: <local path>
image: <image_name>
flavor: <flavor_name>

Then, create a service template, and execute a workflow:

$ aria service-templates store <Example_Root>/openstack-helloworld.yaml <template_name>
$ aria executions start install -s <service_name>

OpenTOSCA Alternative

The Stuttgart Institute of Architecture of Application Systems has been working on TOSCA and a model implementation since 2012. In the form of OpenTOSCA [7], they developed a free system for the TOSCA standard that comprises three parts:

• OpenTOSCA Container, a TOSCA run-time environment
• Winery, a graphical modeling tool for TOSCA
• Vinothek, a portal for applications

OpenTOSCA is already available in version 2.0.0 and can be installed on Debian with:

$ wget -qO- http://install.opentosca.org/install | sh

After installation and startup, which can take up to 10 minutes, an OpenTOSCA instance is available at http://host: 8080 . Access to the Winery components is through the web interface.

Working with OpenTOSCA follows a fixed procedure:

1. Outline the topology and orchestration.

2. Select the NodeTypes.

3. Create a new template in Winery and model the desired topology on the basis of the NodeTypes.

4. Enter the necessary parameters for NodeTemplates.

5. Model and import the plan, including the specification of various service information.

6. Export the service template to a CSAR file.

The developers show which existing application areas are made available by OpenTOSCA through two sample applications that describe IoT services [8] and typical application scenarios in Industry 4.0 [9].