About - day 2 identification of the definition of a node graph

[pmbruun]

Consider those use-cases, where the node graph created from a service template deployment is persisted. I am aware that not all orchestrators have such a model, but some do.

In these cases, for day 2 scenarios you need to be able to come from the node graph and find the configuration of template objects that the node graph was created from. Using includes etc. that may in fact be a combination of versions of CSARs that were available at the time.

As discussed in today's language ad hoc meeting it makes sense to look for existing standards of configuration management for good ways of identifying configurations. We may want to move template_name and tempate_version to an about section.

For the cases were services are deployed based on one CSAR alone, the identification of the only feasible identification is presently the filesystem path and name of the CSAR, which I find not satisfactory.

ETSI clearly faced this problem and for a VNF TOSCA descriptor SOL001 they ended up defining template identification as properties:

• descriptor_id: A globally unique string Identifier of this VNFD information element - typically a UUID. The VNFD Identifier shall be used as the unique identifier of the VNF Package that contains this VNFD. Any modification of the content of the VNFD or the VNF Package shall result in a new VNFD Identifier.
• descriptor_version: A string that identifies the version of the VNFD.
• provider A string defining the provider of the VNF and of the VNFD.
• product_name: A string name to identify the VNF Product. Invariant for the VNF Product lifetime.
• software_version`: Software version of the VNF. This is changed when there is any change to the software that is included in the VNF Package

The only one of these that ETSI specifies to be unique is the descriptor_id - and so when we get to day2 modifications of ETSI VNF descriptors, they define that a TOSCA template can define a policy to indicate that a node graph deployed from one descriptor_id can be migrated "up" or "down" to another descriptor_id - like this example:

tosca_definitions_version: tosca_simple_yaml_1_3
imports:
..
node_types:
  MyCompany.SunshineDB.2_0.2_0:
    derived_from: tosca.nodes.nfv.VNF
    properties:
      descriptor_id:
..
      default: ebc68e34-0cfa-40ba-8b45-9caa31f9dcb5       ###### My ID ( I am V2)
..
  interfaces:
    MyCompanyChangeCurrentVnfPackage:
      type: MyCompany.interfaces.nfv.ChangeCurrentVnfPackage   #### TOSCA interface ~= hook
..
interface_types:
  MyCompany.interfaces.nfv.ChangeCurrentVnfPackage:
    derived_from: tosca.interfaces.nfv.ChangeCurrentVnfPackage
    operations:
      change_from_version_1:
        description: operation for change from version 1 to 2
..
      change_to_version_1:
        description: operation for change from version 2 to 1
...
topology_template:
..
  node_templates:
    sunshine_db:
      type: MyCompany.SunshineDB.2_0.2_0
..
      interfaces:
        MyCompanyChangeCurrentVnfPackage:
          operations:
            change_from_version_1:
              implementation: change-from-version-1.workbook.mistral.yaml #### REAL script (this is mistral, could be shell or python)
            change_to_version_1:
              implementation: change-to-version-1.workbook.mistral.yaml
  policies:
..
  - change_from_version_1:
    type: tosca.policies.nfv.VnfPackageChange
    properties:
      selector:
        source_descriptor_id: b1bb0ce7-ebca-4fa7-95ed-4840d70a1177  ## vnfdid of the V1 package
        destination_descriptor_id: ebc68e34-0cfa-40ba-8b45-9caa31f9dcb5 ## My id again (I am V2)
        source_flavour_id: simple
      modification_qualifier: up        ### This is what tells VNFM that this is an upgrade
      additional_modification_description: ..
...
      triggers:
        - change_from_version_1:
          event: tosca.interfaces.nfv.Vnflcm.change_current_package_notification
          action: tosca.interfaces.nfv.MyCompanyChangeCurrentVnfPackage.change_from_version_1
  - change_to_version_1:
    type: tosca.policies.nfv.VnfPackageChange
    properties:
      selector:
        source_descriptor_id: ebc68e34-0cfa-40ba-8b45-9caa31f9dcb5      ### Ids reversed here
        destination_descriptor_id: b1bb0ce7-ebca-4fa7-95ed-4840d70a1177
        source_flavour_id: default
      modification_qualifier: down
....

What this is intended to mean is, for example, that a node graph deployed from the template with descriptor_id: b1bb0ce7-ebca-4fa7-95ed-4840d70a1177 can be up-graded to the template with descriptor_id: ebc68e34-0cfa-40ba-8b45-9caa31f9dcb5. As a minimum this requires that we can identify a template by the value of the descriptor_id in one of the nodes in the node graph.

I hope we agree that this approach is not what we should recommend.

The problem I see is that our TOSCA 2.0 specification does not provide a good alternative to the above.

In my world, I would have liked that at least there should be a well-defined template_name and template_version that was guaranteed to be unique. The current TOSCA 2.0 specification says:

Some service templates are designed to be referenced and reused by other service templates and have a lifecycle of their own. Therefore, in these cases, a template_version value SHOULD be included and used in conjunction with a unique template_name value to enable lifecycle management of the service template and its contents.

My point here that referencability is not only for refences between templates, but also between the templates and the node graph, extending the need further than originally envisaged.

What would happen if we wrote "MUST" instead of "SHOULD"? This would give the template a unique name independent of where the CSAR happened to be placed in the file-system when it was unpacked.

I am probably overlooking a lot of additional complexity - so I won't say what "the solution" should be - only that when we leave open a hole in the language, the users get creative and misuse other constructs.

[pmbruun]

Our current section 5.2.1.3.6.2 Grammer says template_version: <version> where in other places we have <string>. The version is defined in 5.4.2.1.1 Grammar as the "TOSCA version": <major_version>.<minor_version>[.<fix_version>[.<qualifier>[-<build_version>] ] ]

Down to fix_version this format has the benefit of defining a clear way that an orchestrator can compare two versions to determine which one is newer than the other. The qualifier is not comparable.

Was this the intention?

What could an orchestrator do with that information? It could be given an order to upgrade a service to its latest version. That could make sense if the latest version were a mandatory security patch.

Personally, I think it would be useful to enforce this format - making name and version mandatory, because what happens today - as was mentioned in the meeting - is that people concoct arbitrary encodings of versioning into their CSAR names, node names, properties, etc.

I suggest that any standard - whatever we decide - is better than wild-west naming.

[lauwers]

I completely agree. TOSCA should support (semantic) versioning of profiles and service templates.

[lauwers]

I'd like to revisit this issue during one of our upcoming TOSCA Language ad-hoc meetings. In particular, I'd like us to decide exactly what entities need to be (uniquely) named and versioned. Do we version individual topology templates inside a TOSCA file, or do we version the entire file? What if that file also defines a profile? Is that profile versioned separately from the TOSCA file? What if the CSAR contains multiple TOSCA files? Do we version the CSAR as a whole or do we version each individual file?