get_property for the artifact.file field

[jpc4242]

Before raising an issue, I'd like to check if this is even valid (I didn't find anything in the TOSCA document either allowing or forbidding, but maybe I didn't look had enough).
A colleague tried to use get_property as a way to assign the file corresponding to an artifact in a node, taking the file name from a property (on a different node)

....
  (inside node_templates)
  node1:
     type: xxxx
     properties:
         ppp: theimagename
...
  node2:
     type: yyyy
     .....
     artifacts:
         sw_image:
            file: { get_property: [node1 ppp] }

but puccini is not accepting that the file field may contain a tosca function and complains with:
topology_template.node_templates["node2"].artifacts["sw_image"].file: "map" instead of "string"

Is this a defect in puccini? Or does TOSCA limit the range of situations where TOSCA functions are accepted and therefore you cannot use get_property here?

P.S.: If you confirm that this is an issue, I'll ask my collegue to prepare a simplified test case and attach it to the issue.

TIA,
JPC

[tliron]

This is by design, at least for now. (No need to submit a test case.)

Functions in TOSCA can be used in values, which means assignments of properties, attributes, parameters, inputs, and outputs. The use of functions is highly tied to TOSCA data types, and these are the only places in TOSCA which are typed in this way.

Now, arbitrary keywords in TOSCA are also "typed", but these are YAML types, not TOSCA data types. For example, this file keyword requires a YAML string.

We've discussed this issue in the TOSCA committee and the consensus, at least at the time, was that allowing these functions everywhere could open a can of worms. It's hard to follow through with the implications of this. For example, some keywords directly affect what is possible in other parts of the grammar.

At the end of the day TOSCA is a fairly static language and does not really support parameterized graphs. Even requirement fulfillment is deterministic.

Unfortunately the workaround for your use case may be passing TOSCA through a templating language (such as Jinja2). Another approach might be to attach several artifacts to the node template and then use a value (maybe an operation input) as a way of choosing which artifact to use.

[jpc4242]

Unfortunately the workaround for your use case
As a matter of fact I already told mu colleague that this use case was invalid (for a different reason, this was an ETSI VNF Package and you cannot in that case arbitrarily modify the image). But since the situation happened I wanted to know the answer for the general case.

And now I have that answer; your explanation makes perfect sense.

Thanks a lot,
JPC