Skip to content



Figure 1: The different deployment variants.

This document holds a detailed step-by-step guide to deploy the development variant of the motivating scenario. The motivating scenario is a simple composite application that consists of a web component and a database, as presented in Figure 1.

This application can be deployed in different variants. During development the application should be deployed on a single virtual machine. However, for the productive operation, an elastic deployment is required and, therefore, the application is deployed on Google Cloud Platform (GCP).


We need to fulfill the following requirements to follow this step-by-step guide.

  • Access to an OpenStack instance
  • Ubuntu 22.04
  • Git
  • xOpera


First, we install OpenTOSCA Vintner. For more information see Installation.

curl -fsSL | sudo bash -

Next, we configure xOpera as the orchestrator that should be used for the deployment. For more information see Orchestrators.

vintner orchestrators init xopera
vintner orchestrators enable --orchestrator xopera

Import the Template

Variability4TOSCA template

Figure 2: The Variability4TOSCA template.

First, we clone the repository.

git clone
cd opentosca-vintner
git lfs install
git lfs pull

Next, we import the Variability4TOSCA template.

vintner templates import --template motivation --path examples/motivation

Next, we initialize an application instance.

vintner instances init --instance motivation --template motivation

We can optionally inspect the Variability4TOSCA template. This template contains all possible elements having conditions assigned. For example, the virtual machine hosted on OpenStack has a condition assigned that checks if the development variant has been chosen. An overview is given in Figure 2.

vintner templates inspect --template motivation

Resolve Variability

TOSCA Template

Figure 3: The deployment variant.

We intend to deploy the development variant. Therefore, we need to resolve the variability by providing respective variability inputs. In our case, we use already predefined variability inputs by using a variability preset.

vintner instances resolve --instance motivation --presets dev

We can optionally inspect the generated TOSCA-compliant template. This template contains only the nodes required for the development variant. An overview is given in Figure 3.

vintner instances inspect --instance motivation


Finally, we deploy the application. Therefore, we need to provide deployment inputs which contain, e.g., credentials to OpenStack. Possible deployment inputs are specified in topology_template.inputs of the TOSCA-compliant template. The deployment will take some minutes.

vintner instances deploy --instance motivation --inputs ${INPUTS_PATH}


Afterward, we can undeploy the application.

vintner instances undeploy --instance motivation

Optionally, we can remove the instance and cleanup the filesystem. Cleaning up the filesystem removes any data including, e.g., all imported templates and created instances.

vintner instances delete --instance pruning
vintner setup clean --force


This deployment is also executed in our integration pipeline, which is executed once a week. The logs of the corresponding GitHub action can be accessed here. Relevant jobs start with "Unfurl Motivation" and "xOpera Motivation". Note, a GitHub account is required to access these logs. The raw logs are available without requiring an GitHub account.


The assets of this guide can be also found on Zenodo.


This guide is part of our paper published at the Algorithms 2022. Also check our other publications.

Last update: January 13, 2024