Coerce get_attribute referencing requirement

[Shishqa]

Hi!

Is there any way to access the requirement target from the source node?

Here the simple example, which does not work:

tosca_definitions_version: tosca_simple_yaml_1_3

topology_template:

  node_templates:

    server_2:
      type: tosca:Compute
      requirements:
        - dependency: server_1
      interfaces:
        Standard:
          operations:
            create:
              implementation: script.sh
              inputs:
                dependency_address: { get_attribute: [ SELF, dependency, 0, TARGET, public_address ] }

    server_1:
      type: tosca:Compute
      attributes:
        public_address: 1.1.1.1

Puccini gives

> puccini-tosca compile example.yaml --coerce 
PROBLEMS (1)
  file:/home/shishqa/dev/tmp/puccini/example.yaml
    @17,17 topology_template.node_templates["server_2"].interfaces["Standard"].operations["create"].inputs["dependency_address"]: call to tosca.function.get_attribute("SELF","dependency",0,"TARGET","public_address") failed because relationship "dependency" attribute "TARGET" not found in "server_2"

[tliron]

I like your thinking! Unfortunately TOSCA 1.3 does not allow for this, as you can only "travel" once using a "modelable entity name" in the first argument. However, for TOSCA 2.0 we are enabling something that is almost identical to what you are doing. We are calling it "TOSCA Path" and it allows for flexible "traveling" in the graph like you are doing here.

If you are a TOSCA member you can download the latest draft here. We would love to get feedback and even better join our team to help define TOSCA 2.0.

[Shishqa]

As I can see from the first link, TOSCA 1.3 allows travelling using SELF keyword and <optional_req_or_cap_name>. But I now get it, that I've always understood it differently: the <req_name> moves the "traversal context" to the relationship but not to the relationship target. Now it is more clear, thank you!

The above example was inspired by TOSCA 2.0 draft directly, but as it is just a draft, it would be unreasonable to expect puccini to fully support things that may change later. My main misconception was that I thought this was possible in the 1.3 :)

[tliron]

Puccini tries to stay as close to the spec as possible, even when the spec isn't great. :) As you note, the internal 2.0 support is still, obviously, experimental. Indeed I try to add things that feel more "final" so I don't have to constantly rewrite. Actually, it might be time to implement TOSCA Path as it seems the community has agreed on it.