Target Allocation

(see Splitting)

In the repository UI the topology of a Service Template can be allocated to Cloud Providers by clicking the cloud icon and entering the needed information. Cloud Providers for the Node Templates of the topology are selected based on already assigned target locations and three different criteria. Each criteria provides the functionality to only assign target locations or also inject Node Templates of these locations based on the Split & Match method. The resulting topologies are saved in the repository under the same namespace and name as the original topology but with the added suffix “-assigned” or “-allocated” and the number of the generated topology. The target locations are not case sensitive.

Like the Split & Match method, this functionality assumes that topologies are modeled in a specific way:

  • Node Templates have requirements

  • at least one Node Template in the topology has a target location

  • the target locations correspond to a cloud provider namespace containing Service Templates by the cloud provider with matching capabilites

  • only the Node Templates without incoming hostedOn Relationship Templates have target locations assigned

Note: the Split & Match method also supports topology completion and injection of topology fragments with multiple Node Templates. This is not considered here.

Criteria

Minimal amount of host components

Distribute the existing target labels so that PaaS Node Templates are preferred and the resulting topology has a minimal amount of Node Templates.

Fulfillment of policies

Select target locations based on non functional requirements modeled as Policy Templates.

Additional requirements:

  • Node Templates without incoming hostedOn Relationship Templates have Policies

  • names of policies are unique in the topology (name has to be used as ID as Policies have no IDs)

The selection is performed by comparing the Policies of the topology with the Policies of the fragments of the cloud providers. For the comparison the Policies have to have the same type. The comparison is performed by operators, which can be selected in the GUI modal. These operators compare one specified property of the Policies. At the moment, only primitive data types modeled as Winery Key-Value properties are supported for comparison.

Minimal amount of external connectsTo Relationship Templates

Distribute target locations so that amount of external connectsTo Relationship Templates is minimal. A Relationship Template is considered external if it connects Node Templates of different target locations. Note: a randomized algorithm is used, so results can vary.

Additional requirements:

  • each Node Template without incoming Relationship Templates and without target location is (transitively) connected to at least one Node Template with target location

Combination of criteria & topology generation

Each criteria generates permutations of all possibile target location distributions and matching Node Templates of the Cloud Providers. As this can result in the generation of many topologies, which can take a long time, an upper bound of topologies to generate can be specified in the GUI modal (”topology generation cap”).

Generated topologies can also be filtered by the different criteria. For example, topologies generated by the “Minimal amount of host components” can be filtered for minimal external connectsTos. This enables the fulfillment of multiple criteria and the narrowing of the generated topologies.

As target locations can also only be assigned without injecting matching Node Templates from the Cloud Providers, the preferred target location distribution can also be selected manually. After the selection, matching Node Templates can be injected using on of the criteria or the Split & Match functionality.