oasis-open / tosca-community-contributions Goto Github PK

Should maybe be an optional level as there is no fully defined usage of policy types in 1.0 spec ?

There should be a way for a template author to indicate that an output or a property is sensitive, such as a password, so that a TOSCA processor can redact those value in user output, logs, etc.

Maybe add a keyword like "sensitive"?

TOSCA specifications 1.0/1.1/1.2/1.3 contain a lot of examples illustrating the TOSCA features.
This could be interesting to store all these examples into the tosca-community-contributions repository.
Moreover some examples in the specs contain some grammatical/typing errors that we could correct without modifying the specs.

1. TOSCA users could find all the examples without copy/paste them from the specs.
2. TOSCA implementers could find a suite of correct and portable TOSCA examples to test their implementation.

So, this could be helpful for all the community.

Node type scenario 01:

• Node type with all keynames
• See https://github.com/oasis-open/tosca-test-assertions/blob/master/Parser-Validator/3.6.6-capability_types-01-valid.yml for help to get started

Optional ? See #30

Optional ? see #31

Test for a node type with only the required keynames.
See https://github.com/oasis-open/tosca-test-assertions/blob/master/Parser-Validator/3.6.6-capability_types-02-valid-required-only.yml to get started.

Version 1.3 allowed repositories to be declared with a "credential" keyword but that was removed from 2.0. Artifact registries such as container image registries or git repositories very often require authentication so we need to a mechanism to support these use-cases.

Add a non-sequenced requirements definition.
Parsing should fail with syntax error.

Should we introduce a mechanism for generating multiple node templates by templatizing the template name?

(cf TOSCA TC TODO Item 23)

The Known TOSCA Implementations wiki page contains a lot of useful links but readers need to go through all pages to have a big picture of TOSCA implementations.

I propose to add to the wiki a big picture named TOSCA Implementation Landscape, which could be the following one:

Green is for still alive implementations, Red is for retired/stopped implementations.
Packages regroup implementations according to a common goal: High level modeling for producing CSARs, Storing CSARs, Orchestrating CSARS (and NFV artefacts), basic building blocks for TOSCA developers.

What do you think about this big picture?

Are you interested by this contribution?

The spec makes no mention of the regular expression syntax which TOSCA is following. Unfortunately this can vary a bit.

As an example:

• YANG, with its XML heritage, uses XML family syntax: a regex is implicitly always anchored start and end (^ and $ are always implied at the ends)
• JSON Schema uses javascript syntax: a regex is never implicitly anchored so you need to add ^ and $ for most regexp on an attribute

I think the TOSCA spec has to make a statement on this, either to pick a format or say it is engine dependent (which I don’t think is the best choice as this affects portability).

Should maybe be an optional level as there is no fully defined usage of groups types in 1.0 spec ?

See sub-tests #42 #43 #44 #45

TC consensus seems to be it should be possible to declare artifacts on the topology template not just node templates as in TOSCA 1.3. How about relationships, groups, policies, etc.? And to interfaces?

(cf TOSCA TC TODO Item 22)

What to do with "occurrences" keyword in requirements and capabilities, at both the node type and node template levels.

(cf TOSCA TC TODO Item 1)

Prerequisite 3.5.4 Node filter

Relationship type scenario 01:

Relationship type with all keynames
See https://github.com/oasis-open/tosca-test-assertions/blob/master/Parser-Validator/3.6.6-capability_types-01-valid.yml for help to get started

Test for a node type with an undefined parent type (derived_from)

See https://github.com/oasis-open/tosca-test-assertions/blob/master/Parser-Validator/3.6.6-capability_types-03-unknown-parent-type.yml to get started.