Types of validations

The tng-sdk-validate tool can validate descriptors in four levels

• Syntax -s
• Integrity -i
• Topology -t
• Custom rules -c

Every level includes the previous, i.e. if integrity validation is selected, the tool will check syntax first. In the same way, if topology is selected, syntax and integrity will be checked first.

Note: Topology validation can only be used in VNFD and NSD since the rest of descriptors do not form internal networks.

Syntax

The syntax validation checks that the descriptors follow correctly the schemas. For example, it checks all the required fields in the schemas exist in the descriptors. It is necessary to use the following statement to invoke the custom rule validation.

The library jsonschema is used to validate the correct form of them.

Note: Although the descriptors are in YAML format, it is possible to validate them with jsonschema because JSON is a subset of YAML.

jsonschema.validate(descriptor, schema)

Integrity

Integrity validation checks that all the fields have correct values. Duplicated ID in fields, time durations with negative values, two units using the same PORT, etc.

#Example of YML that will pass the syntax validation 
#but not the integrity validation
connection_points:
  - id: "mgmt"
    interface: "ipv4"
    type: "management"
  - id: "mgmt"
    interface: "ipv4"
    type: "management"
  - id: "output"
    interface: "ipv4"
    type: "external"

Every descriptor has different fields, so the integrity validation is different in every case. It is important to mention that when --service validation is invoked, the tool will validate the NSD and the VNFD associated to it.

Topology

The function of the topology validation is to check the sub-networks formed inside VNFD and NSD. The VNFD are composed by smaller units called virtual deployment units. In the same way, the NSD are composed by VNFDs. The topology problems are related with problems with the connectivity among VDUs (in the VNFD case) and among VNFD (in the NSD case). Some problems which will be checked are:

• There are not isolated units (i.e. all the connection points (CP) are not in use).
• There are not CP in use which are not defined.
• There are not loops in the network
• There are not cycles in the network

Note: Cycles only will be checked if virtual links are used.

Custom rules

In the custom rules case, the user can decide rules which the validator must check. Currently, the only rules related with VNFD are supported. It is necessary to use the following statement.

tng-sdk-validate -c --<type_of_descriptor> <path/to/descriptor> --cfile <path/to/custom_rules_yaml>

The YAML file that contains the rules has to have the format:

- conditions:
    all:
      - name: name_condition
        operator: action 
        value: value # value to compare
  actions:
    - name: raise_error
      params:
        error_text: Text error # message that the validator will show if the condition is not accomplish

name_condition field must be:

• vdu_resource_requirements_ram_size
• vdu_resource_requirements_ram_size_unit
• vdu_resource_requirements_cpu_vcpus
• vdu_resource_requirements_storage_size
• vdu_resource_requirements_storage_size_unit
• vdu_resource_requirements_network_network_interface_bandwidth
• vdu_resource_requirements_network_network_interface_bandwidth_unit
• vdu_vm_resource_format

If the rules were numeric (size/bandwidth), operator must be:

• equal_to
• greater_than
• less_than
• greater_than_or_equal_to
• less_than_or_equal_to

If the rules were string type (size unit/ bandwidth unit), operator must be:

• equal_to

Examples of custom rules can be found in samples. More detailed information about custom rules validation is available in (custom rules validation user cases)[https://github.com/sonata-nfv/tng-sdk-validation/wiki/Custom-rules-validation-user-cases]