Closed philippemerle closed 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.
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.
For the following service template
puccini reports the following error
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.