RE: [tosca-comment] Comments on Version 1.2, Public Review Draft 01

Hi Oliver,

Thanks for the detailed review. We’ll need some time to go through your comments but we’ll get back to you over the next couple of days.

Thanks,

Chris

From: tosca-comment@lists.oasis-open.org [mailto:tosca-comment@lists.oasis-open.org] On Behalf Of Oliver Kopp
Sent: Sunday, February 18, 2018 3:18 PM
To: tosca-comment@lists.oasis-open.org
Subject: [tosca-comment] Comments on Version 1.2, Public Review Draft 01

Hi,

While working on a converter from TOSCA XML to TOSCA YAML, we encountered following issues:

## Artifact Properties

- Line 1849 states that Artifact Types have properties.

- Section 3.6.7 (Lines 1188 to 1214) define an Artifact

An Artifact does not have a "Property Assignment"

We think that this should be added. That would be then consistent with "Node templates", which also have a property assignment "for assigning values to named properties (...) defined in their corresponding name types." (Lines 1329 and 1330).

## Types of Artifacts

The extended notation of an Artifact definition (Section 3.6.7.2.2, starting at Line 1200) requires the specification of a type (Line 1206). The short notation does not. This feels a bit inconsistent. Does one always need the type? Does one always know from the file extension which file type it is? Is ".zip" always a "ZIP" file? If yes, why does the extended notation require the type? Why is it not optional? -- I think, it should be always possible to convert a short notation in an extended one. This is not the case here.

## Artifact Files

According to Line 1194, an Artifact can contain a single file only. In TOSCA XML 1.0, artifacts could reference multiple files. See lines 2610 to 2618.

In the general sense (and outlined in the example on page 18), it makes sense. However, what if I want to attach source code somehow? One could also think of an installer with a checksum file. I assume, I "just" have to ZIP the files to comply with the specification. Having a one-to-one relation of artifact and file seems to be an intuitive one.

## Outputs of operations

Section 3.6.15 (starting from Line 1492) defines Operations. An operation has inputs only. What about outputs? We think that it should be possible to specify the interface completely. Only specifying the inputs explicitly and relying on "get_operation_output" does not seem enough. How can one now which values to read using "get_operation_output"?

## Relationship templates

Section 3.8.4 (starting at Line 2224) defines Relationship templates. In case I have four node templates in my topology (n1, n2, n3, n4), where each par can be connected by the same relationship type. Let's say: n1 -> r12 -> n2, n3 -> r34 -> n4. How can I give r12 different properties than r34? The TOSCA XML spec used to have "source" and "target" for relationship templates. I don't find an equivalent in the YAML 1.2 PRD. "source" seems to be used for inheritance (line 2215).

Put in different words: How can I specify a topology graph using TOSCA YAML?

## Workflows

I cannot find the terms "BPEL" and "BPMN" in the specification. It should be allowed to use de-facto BPM languages also in TOSCA.

Side note: The graph on Line 3654 reminds one of graphs defined in BPEL. We once worked on a simple notation for BPEL at http://bpelscript.org/. I am not sure whether YAML is a proper serialization of workflows. https://ballerinalang.org/ is another hot candidate for an orchestration language.

## Description field

In Section 5.9.14.1, Line 3411, the field "description" is used for both a capability and a requirement. Capability definitions have this field (1744), but requirement definitions do not (Line 1786)

## Operation implementation

Section 3.6.14 (starting on line 1453). Line 1457 defines "primary" of type "Artifact definition", but Line 1462 allows the short notation "primary artifact name". The table at line 1457 should also list that type, shouldn't it?

## Wrong reference: Interface assignments do not exist

Line 2132 (Section 3.8.2.2.3) shows "interface_assignments" linking to "3.6.16 Interface definition". Possibly the text at Line 2132 is just wrong.

## Impossible short notation

For the "Property Filter" definition, there is a short notation offered at line 1130 (Section 3.6.4.1.1). We think, this short notation is not possible, as a "constraint clause" is itself a key/value pair. So "example: greater: 2" is invalid YAML, isn't it?

## Missing tosca.entity.Root

- tosca.interfaces.Root derves from tosca.entity.Root (line 3226)

- tosca.nodes.Root derives from tosca.entity.Root (line 3310)

However, the spec does not define tosca.entity.Root

## Missing intro table at tosca.nodes.DBMS

All TOSCA types present a table with "shorthand_name", "type_qualified_name" and "type_uri". This is missing at Section 5.9.7 (should come after Line 3357)

## Inconsistent text

Section 3.7.4.1, Line 1849: The table has "mime_type" as not required, but the text reads "The required mime type". Same for "file_ext".

BTW: The current Java model for TOSCA YAML is available at https://github.com/eclipse/winery/tree/master/org.eclipse.winery.model.tosca.yaml. Since there is still not an official Eclipse Winery release, one has to use https://jitpack.io/ to get the JARs into his implementation.

We are open for discussions.

Greetings from Stuttgart,

Oliver
--
https://github.com/koppor/

The views and opinions expressed in this feedback are those of the author and do not necessarily reflect the official policy or position of the University of Stuttgart or any affiliated institutes or persons.

tosca-comment message