Analysis content

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)

The analysis is based on the following specification :

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 [TOSCA-YAML-1.2]

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 [SOL001]

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

TOSCA Simple Profile YAML NFV 1.0 Referecne: http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html [TOSCA-NFV] (According to Former user (Deleted)TOSCA-NFV's conent has already been incorporated by the early version of [SOL001], and no longer being updated).

Analysis by different types

Analysis Result

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

Analysis Statistics and Suggestion

Class	Type Number which belongs to this class	The Issue Example	Suggestion
A	3	SDC Expand source 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	Fix it to align with the correct TOSCA grammar
B 58	B1 14	B1 issue example:	B1 Fix it to align with the TOSCA spec
B 58	B2: 44	B2 issue example:	Fix it to align with the SOL001 spec
C	90	Grammar is complied with TOSCA spec, but defined by SDC only, those are not included in TOSCA spec or SOL001 spec.	•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, 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.	•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

Options to fix the above issues

Option 1

Fix A and B (including B1 and B2) in Dublin release

Option2

Fix all the issues (A, B, C and D) in Dublin release

Option3

Keep it without any fix, and only correct them when designing the new target internal DM (TIDM):

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

Issue A and B1 have to be avoid
B2 should align with the SOL001 spec
C should be obsoleted and replaced by TIDM or other on-boarding DM (e.g. SOL001)
D should be obsoleted and replaced by TIDM or other on-boarding DM (e.g. SOL001)
Other rules?