Versions Compared

Old Version 28

changes.mady.by.user Lingli Deng

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.

...

Class Type Number which belongs to this classThe Issue ExampleSuggestion
A3

annotation_types:

Code Block
languageyml
titleSDC
collapsetrue
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:

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

C90

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

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

...

  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.