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 user-7acabTOSCA-NFV's conent has already been incorporated by the early version of [SOL001], and no longer being updated).
Methodology: Analysis by different types
- annotation-types
- artifact-types
- capability-types
- categories
- data-types
- group-types
- interface-lifecycle-types
- nfv-types
- normative-types
- policy-types
- relationship-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 |
---|---|---|---|
A | 3 | annotation_types: 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: | 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: | 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)
|
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)
|
2.2 Options to fix the above issues
Option | Description |
---|---|
Minimal Goal | Fix A and B (including B1 and B2) in Dublin release based on [TOSCA-YAML-1.2] and [SOL001] |
Stretch Goal | Fix all the issues (A, B, C and D) in Dublin release, and prioritize types that belong to C and D when designing the new target internal DM (TIDM) |
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.,
- Compliant with TOSCA standards, so that Issue A and B1 have to be avoided
- Compliant with ETSI NFV SOL standards, i.e. B2 should align with the SOL001 spec
- C should be covered and priortized by TIDM
- 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.
5 Comments
Anatoly Katzman
I would rather split this into two different topics:
Below I am going to address these two topics with two different replies. This way we can have a separate discussion thread on each.
Anatoly Katzman
TOSCA Grammar violations
It is true that the TOSCA documents generated by SDC are not always fully compliant with the TOSCA language specs. The most serious case is the 'annotation_type' clause. This TOSCA extension was created before AT&T joined ONAP. As long as AT&T owned both the TOSCA generator and the TOSCA parser, this extension was handled without any problem. The problems started when the ONAP community started applying other parsers. I can see 2 possible options to resolve this case:
Anatoly Katzman
Normative type update
Well, many normative types have been updated since their introduction.
The simplest way, as I see it, would be to just upload the new definitions into the SDC catalog in Dublin, and see where the smoke rises. I am pretty sure that SDC will not be affected by the change, but I am less sure about the run-time components.
A more careful approach is to show the upcoming changes to the run-time PTLs before the change![(smile)](/s/z10khv/8804/xgjkrn/_/images/icons/emoticons/smile.svg)
The change can become very expensive if we will find that the update requires migration of already existing models...
Lianhao Lu
created SDC-2090 - Getting issue details... STATUS to track this normative type update issue
Zu Qiang (Ericsson)
hello, Lianhao Lu Question: what is the expected impacts on the SDC? Is it on service template only? Or any impacts on VF csar or VSP csar? any impacts on the vendor provided on boarding csar file?