implicit null value in definitions

[philippemerle]

Issue Description

The following service template contains 6 implicit null values in definitions:

tosca_definitions_version: tosca_simple_yaml_1_3
data_types: # null value implicitly
capability_types:
  CT: # null value implicitly
node_types:
  NT:
    description: # null value implicitly
    capabilities: # null value implicitly
    requirements: # null value implicitly
topology_template:
  node_templates:
    n1:
      type: tosca.nodes.Compute
      capabilities:
        os: # null value implicitly

TOSCA specification seems to not explicity specify if and when null values in definitions are allowed.

For this service template

• Ubicity Validator reports only one error on data_types:.
• Puccini reports 6 errors.
• Cloudnet TOSCA toolbox reports 6 errors.

This repository contains some service templates with null values in definitions:

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

Proposed Resolution

Explicitly specify in TOSCA 2.0 if and when null values in definitions are allowed.

[lauwers]

Thanks Philippe, I’ll fix Ubicity so it no longer complains about the empty “data_types” section.

In your opinion, what is the problem with allowing null values for these various sections? They all seem harmless to me.

Thanks,

Chris

From: Philippe Merle @.> Sent: Tuesday, May 10, 2022 5:17 AM To: oasis-open/tosca-community-contributions @.> Cc: Subscribed @.***> Subject: [oasis-open/tosca-community-contributions] implicit null value in definitions (Issue #103)

Issue Description

The following service template contains 6 implicit null values in definitions:

tosca_definitions_version: tosca_simple_yaml_1_3

data_types: # null value implicitly

capability_types:

CT: # null value implicitly

node_types:

NT:

description: # null value implicitly

capabilities: # null value implicitly

requirements: # null value implicitly

topology_template:

node_templates:

n1:

  type: tosca.nodes.Compute

  capabilities:

    os: # null value implicitly

TOSCA specification seems to not explicity specify if and when null values in definitions are allowed.

For this service template

• Ubicity Validator reports only one error on data_types:.
• Puccini reports 6 errors.
• Cloudnet TOSCA toolbox reports 6 errors.

This repository contains some service templates with null values in definitions:

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

Proposed Resolution

Explicitly specify in TOSCA 2.0 if and when null values in definitions are allowed.

— Reply to this email directly, view it on GitHubhttps://github.com/oasis-open/tosca-community-contributions/issues/103, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AASPLIJ5B4PPPF6DHJP4HNTVJJHUZANCNFSM5VRMWCOA. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[philippemerle]

Thanks Philippe, I’ll fix Ubicity so it no longer complains about the empty “data_types” section.

Ok now Ubicity reports no error.

In your opinion, what is the problem with allowing null values for these various sections? They all seem harmless to me.

Currently, we have at least two different tool behaviours:

• no error when null value, i.e. Ubicity
• error when null value, i.e. Puccini and Cloudnet TOSCA toolbox

So a service template containing null values is not portable to different TOSCA implementations. This is an issue for TOSCA users.

Accepting null values is not so problematic: TOSCA implementors just need to put if xxx != None: everywhere in their code. They could complain (or not) to have to do that.

My issue is that the TOSCA specification does not explicitly specify if a TOSCA implementation shall or shall not accept null values. I am just asking to explicitly specify this aspect in the spec. We could discuss this during a TC meeting, and decide a common position on this subject.

[philippemerle]

Accepting null values or not accepting null values is a design choice of any YAML-based language. For instance, Kubernetes manifests can not contain null values according to the schema at https://raw.githubusercontent.com/kubernetes/kubernetes/v1.22.1/api/openapi-spec/swagger.json. On the other side, Compose specifies that some keywords but not all keywords accept null values according to the Compose schema at https://github.com/compose-spec/compose-spec/blob/master/schema/compose-spec.json. But both explicitly specify if and when null values are allowed. We should take a decision for TOSCA.

[lauwers]

Yes, let's decide during the Language Ad-Hoc meeting. My vote is in favor of making things as easy as possible for service template and profile authors, even if it requires a little bit more work for Orchestrator vendors.

[philippemerle]

I don't see how accepting null values will make things as easy as possible for somebody;-)

Anyway if we accept null values then we would need to update each BNF-like grammar section to explicitly specify which keynames accept null values. A lot of editorial works in perspective ;-(

We could also specify at the beginning that null values are accepted everywhere but we should specify what the semantics of null values is everywhere.

For instance what is the semantics of the following fragment?

node_templates:
  n:
    type: tosca.nodes.Compute
    capabilities:
      os: # implicit null value

Write the following is certainly easier or at least more concise

node_templates:
  n:
    type: tosca.nodes.Compute

So you could imagine that my vote will be against accepting null values in any place;-)

[tliron]

I also think implicit nulls introduce potential ambiguities. There are various places in TOSCA where just the act of writing something down could be understood as "activating" a feature. But then a null could be reasonably understood by readers as a way to disable the feature.

Also note that enabling support for "implicit" nulls really just means enabling support for nulls. Explicit nulls would count, too. So this would have to be legal TOSCA:

node_templates: null

I can think of three examples of ambiguity: requirement assignments, operation assignments, and valid_source_types.

Writing down a requirement "activates" at least one slot of the named requirement definition from the node type (using count can make more than one). If no keyname is used, we will assume keyname values from the requirement definition are to applied unchanged. But ... it is also reasonable to look at an assignment of "null" as not counting at all.

In a lot of TOSCA you can see operations, at interface types, given the {} empty map shorthand, to show that the operation is named but not otherwise defined. Imagine the interface type inherits from another. A null value could be reasonably understood by a reader to mean that the operation should be disabled rather than inherited as is.

In valid_source_types you can provide an empty list, which could be understood to mean that no relationship is possible (no node type would fit). But then a null is, emphatically, not an empty list. It could be understood to mean that this feature is not being used, thus all relationships are enabled. It's in fact the exact opposite meaning. I suspect that many uses of type lists in TOSCA embed this potential confusion.

I'm in favor of keeping keyname values explicitly typed, {} and [], and thus avoiding any potential misinterpretations of the grammar. Null should not be an equivalent for these.

If we do decide to allow for null, I agree with @philippemerle -- it would be our responsibility to scour the entire TOSCA spec to consider the semantic meaning of null in each case.

[lauwers]

We don't have support in TOSCA for "disabling" a feature (none of our refinement rules allow it) so I would be surprised if anybody would assume that "null" could be used for this purpose. Based on your argument, is it safe to assume that "null" is never a valid value for TOSCA keywords?

[tliron]

I indeed think the only place a YAML null would make sense is as a value for the "nil" TOSCA type, which is itself of very limited usability. We've essentially introduced the nil type for completion, say for interoperability with external data models. What is null, really, in the context of a strongly typed language? Null could make sense as an uninitialized pointer, but TOSCA does not have pointers. Other types have their own zero values: 0 for integers and floats, an empty string for strings, and empty lists and maps.

Of course I understand that what is being proposed here is syntactical rather than grammatical: essentially it's intended to be sugar to avoid typing in {} and [] in certain circumstances. But I feel that an explicit null value introduces a cumbersome inconsistency to the language structure. As @philippemerle points out, we would have to spec out null support clearly for those keynames that could allow it. I think the cons outweigh the single potential pro.