This page is a place to discuss and document our understanding of and rules for how referencing and versioning between TOSCA data types, policy types, and policies work.

Versioning

Versions of entities in TOSCA is poorly supported. One can specify versions on definitions of entities but not when referencing those entities from other entities.  For example, when specifying the data type of a porperty in a policy type, the TOSCA definition says to specify it as a string. It is not possible to specify which version of a data type one is using.

CRUD with versions of Data Types, Policy Types and Policies

Chenfei Gao Would you perhaps write this section?

Referencing Data Types and Policy types

Today, when referencing a policy type from a data type, we add the "type_version" field:

tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
    policies:
    -   operational.restart:
            type: onap.policies.controlloop.operational.common.Drools
            type_version: 1.0.0

An alternative that could work with all references could be as follows:

tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
    policies:
    -   operational.restart:
            type: onap.policies.controlloop.operational.common.Drools#1.0.0

In other words, the '#' character acts as a delimiter between the type name and its version.

An alternative that could work with all references could be as follows:

tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
    policies:
    -   operational.restart:
            type: onap.policies.controlloop.operational.common.Drools

Not specifying a version means to use the latest version available.

Reading Data Types and Policy Types

When a data type or a policy type is read from the database:

  1. The requested entity is returned
  2. Any data types referenced by the requested policy type or data type are returned
  3. Any Policy types from which a requested policy type inherits are returned

Creating Policy Types and Data Types

When creating policy types:

  1. If the existing explicitly defined policy type already exists, an error is returned
  2. If a parent of the policy type does not exist, it is created
  3. if a parent of the policy type exists
    1. If the parent definition is the same as whats in the database, then its OK
    2. If the parent definition is different on the incoming specification, then an error is reported
  4. For child data types specified on the incoming policy type definition
    1. If the data type definition does not exist, it is created
    2. If the data type definition exists
      1. If the data type definition is the same as whats in the database, then its OK
      2. If the incoming data type definition is different to whats in the database, then an error is reported

When creating data types:

  1. If the existing explicitly defined data type or data type already exists, an error is returned
  2. If a parent of the data type does not exist, it is created
  3. if a parent of the data type exists
    1. If the parent definition is the same as whats in the database, then its OK
    2. If the parent definition is different on the incoming specification, then an error is reported
  4. For child data types specified on the incoming data type definition
    1. If the data type definition does not exist, it is created
    2. If the data type definition exists
      1. If the data type definition is the same as whats in the database, then its OK
      2. If the incoming data type definition is different to whats in the database, then an error is reported
    3. If a referenced child definition does not exist in the database, then an error is reported


  • No labels