tliron / puccini

Cloud topology management and deployment tools based on TOSCA
https://puccini.cloud
Apache License 2.0
88 stars 20 forks source link

outputs without type field #106

Closed philippemerle closed 2 years ago

philippemerle commented 2 years ago

For the following service template

tosca_definitions_version: tosca_simple_yaml_1_3
topology_template:
  node_templates:
    compute:
      type: tosca.nodes.Compute
      attributes:
        public_address: my.compute.com
  outputs:
    compute_public_address:
      value: { get_attribute: [compute, public_address] }

puccini reports the following error

$ puccini-tosca parse puccini-output_without_type.yaml 
PROBLEMS (1)
  file:/.../puccini-output_without_type.yaml
    @10,5 topology_template.outputs["compute_public_address"].type: missing required field

According to Section 3.6.14.1 of TOSCA 1.3 or Section 4.4.11.1 of TOSCA 2.0, the type keyname is not required/mandatory. For info, this template is validated by Ubicity Validator, xOpera and my own parser.

tliron commented 2 years ago

The type keyname is indeed not mandatory in Puccini. However, there will be an error if it is not finally present. In this case I assume that your own parser extracts the type via the retrieved attribute in the get_attribute function. However Puccini intentionally does not assume anything regarding the return type of functions.

I'm not sure how best to handle this.

tliron commented 2 years ago

OK. I have a solution, but it has some subtleties. For parameters only (and not for attributes and properties) I am allowing them to remain finally untyped, thus the parser will not emit an error.

Strictly speaking this will adhere to the TOSCA spec. However, I imagine that other TOSCA processors may handle this differently. In Puccini if you list the topology outputs then for those to which you have not explicitly ascribed a type indeed you will not see a type. However, you will see a value, which is the result of the function call.

I don't think this as a particularly bad outcome, but it may be an issue for specific implementations that rely on the type metadata. In that case, I would recommend users explicitly set a type in order to avoid any ambiguity.