Versions Compared

Old Version 7

changes.mady.by.user Lianhao Lu (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Anatoly Katzman

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Types that doesn't comply with the Tosca or ESTI NFV SOL001 or Tosca-nfv syntax

Specification reference:

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

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

                                                           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  Referecne:  http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html [TOSCA-NFV]    

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).

...

tosca.artifacts.Root

tosca.artifacts.Deployment

tosca.artifacts.Deployment.Image

tosca.artifacts.Deployment.Image.VM

tosca.artifacts.Implementation

tosca.artifacts.Implementation.Bash

tosca.artifacts.Implementation.Python

tosca.artifacts.File

...

Methodology: Analysis by different types

Child pages (Children Display)
alltrue

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

...

tosca.capabilities.Root

tosca.capabilities.Attachment

tosca.capabilities.Node

tosca.capabilities.Endpoint

tosca.capabilities.Endpoint.Database

tosca.capabilities.OperatingSystem

tosca.capabilities.Scalable

tosca.capabilities.network.Bindable

...

org.openecomp.capabilities.PortMirroring

org.openecomp.capabilities.AllottedResource

org.openecomp.capabilities.Metric

...

tosca.capabilities.Endpoint.Public

Code Block
languageyml
collapsetrue
tosca.capabilities.Endpoint.Public:
  derived_from: tosca.capabilities.Endpoint
  properties:
    network_name: PUBLIC
    ... ...

...

  • 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 classThe Issue ExampleSuggestion
A3

annotation_types:

Code Block
languageyml
titleSDC
collapsetrue
tosca
org.
capabilities
openecomp.
Endpoint
annotations.
Admin
Source:
derived_from
  description:
tosca.capabilities.Endpoint
Indicates the origin
properties:
source of an 
input
secure:
truesame as [TOSCA-YAML-1.2]

SDC's definitions doesn't follow TOSCA grammar, it should be a SDC bug.

The grammar correct definition should be as the following:

Code Block
languageyml
titletosca.capabilities.Endpoint.Public
collapsetrue
tosca.capabilities.Endpoint.Public:
derived_from
properties:
tosca.capabilities.Endpoint
properties:
network
source_
name
type:
type:
string
   type: string
default:
PUBLIC
constraints
vf_module_label:
-
equal:
PUBLIC
... ... Code Block
languageyml
titletosca.capabilities.Endpoint.Admin
collapsetrue
tosca.capabilities.Endpoint.Admin: derived_from: tosca.capabilities.Endpoint properties:
 type: list
secure
description: List of VF Modules this input
type:
was
boolean
originated from
default:
true
    entry_schema:
constraints:
-
equal: truetosca.capabilities.Container.Dockerquite like the tosca.capabilities.Container.Docker
 defined [TOSCA-YAML-1.2]

Compared to [TOSCA-YAML-1.2], the following properties are missing in SDC's definition:

Code Block
languageyml
titlemissing properties:
collapsetrue
... ... properties:
type: string
host
param_
id
name:
type:
string
required
type:
false
string
volume_id:
type
description:
string
Source
required: falsetosca.capabilities.network.Linkable

R3 CSAR 

vCPE：

View file
nameresource-VcpeInfrastructureBgremuDemoApp-csar.csar
height250
View file
nameresource-VcpeInfrastructureDemoApp-csar.csar
height250
View file
nameresource-VcpeInfrastructureGwDemoApp-csar.csar
height250
View file
nameresource-VcpeInfrastructureMetroVbngDemoApp-csar.csar
height250
View file
nameresource-VcpeInfrastructureVgmuxDemoApp-csar.csar
height250
View file
nameservice-VcpeE2eYy-csar.csar
height250
View file
nameservice-VcpeWithAll-csar.csar
height250

CCVPN:

View file
nameservice-Sdwanvpninfraservice-csar.csar
height250
View file
nameservice-Siteservice-csar.csar
height250
View file
nameservice-Sotnvpninfraservice-csar.csar
height250

...

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:

Image Added

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:

Image Added


Proposal: Fix it to align with the latest SOL001 spec [SOL001] in Dublin Release

C90

Image Added

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)

D17

Image Added

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

Option

Description

Minimal GoalFix 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.,

  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.