RE: TOSCA examples from spec

[Chris Lauwers <lauwers@ubicity.com>]

Thanks Philippe for checking these. We will dramatically speed up improvements to the language if we all check one-anotherâs code.

 

By the way, I included the tosca-comment email distribution list on this reply to solicit more feedback.

 

I include comments below in-line:

 

From: Philippe Merle <philippe.merle@univ-lille.fr>
Sent: Friday, January 28, 2022 4:41 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Tal Liron <tliron@redhat.com>
Subject: Re: TOSCA examples from spec

 

Hi Chris and Tal,

 

Thank @Chris to recently start adding service template examples for the TOSCA Simple Profile Version 1.3 specification, see https://github.com/oasis-open/tosca-community-contributions/commit/062511c04ecb244de71aca33dd99d6cf40767be2

 

I parsed these templates with both Cloudnet TOSCA Toolbox and Puccini and there are few parsing issues.

 

At https://github.com/oasis-open/tosca-community-contributions/blob/master/examples/1.3/examples-from-spec/hello-world/hello-world.yaml#L9

and https://github.com/oasis-open/tosca-community-contributions/blob/master/examples/1.3/examples-from-spec/inputs-and-outputs/inputs-and-outputs.yaml#L10

and https://github.com/oasis-open/tosca-community-contributions/blob/master/examples/1.3/examples-from-spec/mysql/mysql.yaml#L9

and https://github.com/oasis-open/tosca-community-contributions/blob/master/examples/1.3/examples-from-spec/mysql/non-normative-types.yaml#L6

 

   template_version: 1.3

 

must be replaced by

 

   template_version: "1.3"

 

because 1.3 is a yaml float and metadata are of type map of strings (Section 3.6.2.2 of TOSCA 1.3 spec).

Yes, my apologies. In the Ubicity parser, I run in a more permissive mode by default that doesnât enforce string values in metadata. I find this overly restrictive, and I donât see any benefit to limiting metadata to strings (nor do I see any downside to allowing arbitrary values since metadata are purely for informational purposes and not intended to be used for anything). This is a topic Iâd like to revisit before we release v2.0.

At https://github.com/oasis-open/tosca-community-contributions/blob/master/examples/1.3/examples-from-spec/inputs-and-outputs/inputs-and-outputs.yaml#L34

 

   os:

 

must be commented because the yaml value is null or must be replaced by:

 

   os: {}

Just because the YAML value is ânullâ doesnât mean this is invalid TOSCA in my opinion. Unfortunately, the TOSCA spec doesnât state how a TOSCA parser should interpret a null value. I interpret ânullâ to be equivalent to âthis is emptyâ or âthere is nothing hereâ.

 

Remember, the whole reason TOSCA switched to YAML instead of XML (or JSON, for that matter) was to make it as easy as possible for profile and template designers to create TOSCA files. Forcing designers to put empty curly brackets here feels unnecessary to me. Unless Iâm missing a reason for why this canât be parsed correctly, I would prefer to allow âemptyâ  (or ânullâ) values for keywords that donât have mandatory values.

 

At https://github.com/oasis-open/tosca-community-contributions/blob/master/examples/1.3/examples-from-spec/mysql/non-normative-types.yaml#L35

 

   short_name: Container.Docker

 

must be removed because short_name is not a valid TOSCA keyname. This could be defined as a metadata.

Yes, I meant to remove this. In my parser, I added the non-standard âshort_nameâ keyword to support the short type names specified in the Simple Profile since there is no standard mechanism for doing this. Using metadata for this purpose would be equally non-standard, but at least it wouldnât cause errors with other parsers.

 

Iâm curious how your parser handles these short type name definitions in the Simple Profile?

 

At https://github.com/oasis-open/tosca-community-contributions/blob/master/examples/1.3/examples-from-spec/mysql/non-normative-types.yaml#L101

the following line is missed:

 

   capability: tosca.capabilities.Compute

 

because capability is a required keyname for requirement definition (Section 3.7.3.1 of TOSCA 1.3 spec).

This is not a requirement definition, but rather a requirement refinement: the âhostâ requirement in  tosca.nodes.Database.MySQL refines the âhostâ requirement that was previously defined in the tosca.nodes.Database node type from which tosca.nodes.Database.MySQL derives. Since the capability type was already defined previously and remains unchanged, there is no need to repeat it in the requirement derivation, and in my opinion requiring profile designer to repeat this would introduce an unnecessary burden without adding any value (this is the DRY principle: donât repeat yourself). We have added a lot of additional clarification about entity refinements, and weâll make sure to get this fully agreed to and completed before releasing Version 2.0.

 

What do you think about these issues?

 

I could produce a PR if needed.

 

A+

Philippe Merle

 

Again, I very much appreciate you checking these.

 

Thanks,

 

Chris