1 Problem Statement

Motivation

To perform an indepth analysis of the current TOSCA types as defined and supported in SDC, and use it as input for the feasibility assessement and requirement analysis for implementing ONAP Generic Tosca Parser to be used by different consumers in run time dealing with TOSCA CSARs packages either externally onboarded via External API or internally distributed from SDC.

Analysis input

Mainly focus on the TOSCA types currently included and used in SDC which can be found  in https://gerrit.onap.org/r/gitweb?p=sdc.git;a=tree;f=catalog-be/src/main/resources/import/tosca;hb=refs/heads/master,  except the heat-types (directory)

References

The analysis is based on the following specifications :

[TOSCA-YAML-1.2]  TOSCA Simple Profile YAML 1.2 Referecne:  http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/TOSCA-Simple-Profile-YAML-v1.2.html  

[SOL001]                   ESTI NFV-SOL 001 V2.5.1 Reference: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/001/02.05.01_60/gs_NFV-SOL001v020501p.pdf  

                                                           https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/001/02.05.01_60/gs_NFV-SOL001v020501p0.zip (YAML definitions)

[TOSCA-NFV]            TOSCA Simple Profile YAML NFV 1.0 Referecne:  http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html   

Note: (According to @Former user (Deleted)TOSCA-NFV's conent has already been incorporated by the early version of  [SOL001], and no longer being updated).

Methodology: Analysis by different types

2 Analysis Output

According to the analysis results, the model problems found can be summarized into four categories:

• A :  Not comply with tosca grammar 
  This classification is used to record types that don't comply with the basic tosca  syntax specification

• B1:  Not comply with existing TOSCA-simple-YAML-1.2

• B2: Not comply with existing SOL001-v2.5.1
  Type definitions quite like the types which defined in specification, but still have some difference， such as base type difference, property difference, etc

• C:  SDC private extension 
  This classification is used to record SDC private extension 
  
  
  

• D:  Use Case private extension
  This classification is used to record  the extension types which used to support specific use case 

2.1 Analysis Statistics and Suggestion

Class	Type Number which belongs to this class	The Issue Example	Suggestion

Class	Type Number which belongs to this class	The Issue Example	Suggestion
A	3	annotation_types: SDC org.openecomp.annotations.Source: description: Indicates the origin source of an input properties: source_type: type: string vf_module_label: type: list description: List of VF Modules this input was originated from entry_schema: type: string param_name: type: string description: Source parameter name Missing derived_from in the definition	Recommendation: Fix it to align with the correct TOSCA grammar as defined in [TOSCA-YAML-1.2] in Dublin Release.
B 58	B1 14	B1 issue example: Open	Recommendation: Fix it to align with the TOSCA normative types as defined in [TOSCA-YAML-1.2] in Dublin Release
	B2: 44	B2 issue example: Open	Proposal: Fix it to align with the latest SOL001 spec [SOL001] in Dublin Release
C	90	Grammar is complied with TOSCA spec, but defined by SDC only, those are not included in TOSCA spec or SOL001 spec.	Proposal: To be aligned with the coming target internal DM (ONAP Target Internal DM (TIDM), Base Proposal) Which types have to be kept ? Which types can be replaced by the TOSCA normative types as defined in [TOSCA-YAML-1.2] or NFV types as defined in [SOL001], or the types as defined in the target internal DM (ONAP Target Internal DM (TIDM), Base Proposal)
D	17	Grammar is complied with TOSCA spec, but defined and used by SDC for a specific use case or vendor, those are not included in TOSCA spec or SOL001 spec.	Proposal: To be aligned with the coming target internal DM (ONAP Target Internal DM (TIDM), Base Proposal) Which types have to be kept ? Which types can be replaced by the TOSCA normative types as defined in tosca-simple-profile-yaml or NFV types as defined in SOL001

2.2 Options to fix the above issues

2.3 Considerations for TIDM Design and Generic Parser Implementation

The rules for designing TIDM and implementing generic parser have to be considered and decided in Dublin release, e.g.,

1. Compliant with TOSCA standards, so that Issue A and B1 have to be avoided

2. Compliant with ETSI NFV SOL standards, i.e. B2 should align with the SOL001 spec

3. C should be covered and priortized by TIDM

4. D should be covered and priortized by TIDM

All the existing Data model should be managed and published by modeling subcommittee，and modeling subcommittee also need consider how to manage the different version of model.