Follow up on the boundary definition section

[Luca Gioppo <luca.gioppo@csi.it>]

I have some more use cases for the need of a boundary definition section.

 

The goal here is to have a place at ServiceTemplate level to express the needs for external components in the orchestrator environment:

 

USE CASE

The Service descried in the TOSCA file REQUIRE the presence of a monitoring system or of a backup system or a devops system

If the requirement is not met than the orchestrator needs to follow the disposition of the requirement

 

The proposed modeling is as follows:

 

boundary_definitions:
# section to gather requirements for the whole template
  requirements:
    monitoring:
      type: tosca.monitoring.system.Zabbix.external
      properties:
        disposition: Required
    dev_ops:
      type: tosca.dev_ops.system.Puppet.external
      properties:
        disposition: Required
    backup:
      type: tosca.backup.system.Bacula.external
      properties:
        disposition: Best-effort

This will solve some needs coming from the monitoring but also from other generic components.

 

Other generic environment could be:

- DNS

- schedulers

- central LDAP

- any centralized system that the service will not deploy but will use

 

The modeling proposed allows to presen some use cases for some of the most immedate examples and to leave implementors open path in adding value added features to the orchestrator since those are the ones that could make customers choose one in place of another.

 

Luca