interfaces without explicit operations keyword (deprecated syntax)

[jpc4242]

Hi, this comes from a discussion with a ETSI SOL001 vendor.

TOSCA 1.3 uses operations and notifications; but it also says that

3.6.20.3 Notes Starting with Version 1.3 of this specification, interface definition grammar was changed to support notifications as well as operations. As a result, operations must now be specified under the newly introduced operations keyname and the notifications under the new notifications keyname. For backward compatibility if neither the operations or notifications are specified then we assume the symbolic names in the interface definition to mean operations, but this use is deprecated. Operations and notifications names should not overlap.

Vendor is using TOSCA 1.3 and interfaces without including operations (i.e: the "deprecated" syntax. Puccini is complaining about it. I don't have their permission to publish here the original descriptor so I created a simplified example (at the end of this message).

Puccini complains about every bit where I don't use operations. If I understood it correctly, the "deprecated syntax" would allow at least some of them.

$ puccini-tosca parse s1_2.yaml
PROBLEMS (4)
  file:/home/juan/myenvs/TOSCA/PT6_328/tests/s1_2.yaml
    @5,5 interface_types["myinterfacetype1"].instantiate: unsupported keyname
    @32,9 node_types["mytype"].interfaces["myinterface0b"].instantiate: unsupported keyname
    @47,9 node_types["mytype"].interfaces["myinterface1b"].instantiate: unsupported keyname
    @62,9 node_types["mytype"].interfaces["myinterface2b"].instantiate: unsupported keyname

Would it be possible for puccini to support the deprecated syntax? Either by default or with some quirk (e.g -x allow_deprecated_interface_syntax). In the last case, including it also as part of -x etsinfv combination quirk

TIA, Juan

tosca_definitions_version: tosca_simple_yaml_1_3
interface_types:
  myinterfacetype1:
    derived_from: tosca.interfaces.Root
    instantiate:
      inputs:
        additional_parameters:
          type: string
          required: true
  myinterfacetype2:
    derived_from: tosca.interfaces.Root
    operations:
      instantiate:
        inputs:
          additional_parameters:
            type: string
            required: true
node_types:
  mytype:
    derived_from: tosca.nodes.Root
    interfaces:
      myinterface0a:
        type: tosca.interfaces.Root
        operations:
          instantiate:
            inputs:
              additional_parameters:
                type: string
                required: true
      myinterface0b:
        type: tosca.interfaces.Root
        instantiate:
          inputs:
            additional_parameters:
              type: string
              required: true
      myinterface1a:
        type: myinterfacetype1
        operations:
          instantiate:
            inputs:
              additional_parameters:
                type: string
                required: true
      myinterface1b:
        type: myinterfacetype1
        instantiate:
          inputs:
            additional_parameters:
              type: string
              required: true
      myinterface2a:
        type: myinterfacetype2
        operations:
          instantiate:
            inputs:
              additional_parameters:
                type: string
                required: true
      myinterface2b:
        type: myinterfacetype2
        instantiate:
          inputs:
            additional_parameters:
              type: string
              required: true

[tliron]

Yes, it should not be hard to do. Just out of curiosity, this does work OK if you use tosca_definitions_version: tosca_simple_yaml_1_2?

[jpc4242]

If you use 1_2 then it complains about the "complementary"set (i.e the format that includes "operations")

$ puccini-tosca parse s1_3_using_tosca_1_2.yaml
PROBLEMS (4)
  file:/home/juan/myenvs/TOSCA/PT6_328/tests/s1_3_using_tosca_1_2.yaml
    @13,7 interface_types["myinterfacetype2"].operations.instantiate: unsupported keyname
    @25,11 node_types["mytype"].interfaces["myinterface0a"].operations.instantiate: unsupported keyname
    @40,11 node_types["mytype"].interfaces["myinterface1a"].operations.instantiate: unsupported keyname
    @55,11 node_types["mytype"].interfaces["myinterface2a"].operations.instantiate: unsupported keyname

$ puccini-tosca parse s1_3_using_tosca_1_3.yaml
PROBLEMS (4)
  file:/home/juan/myenvs/TOSCA/PT6_328/tests/s1_3_using_tosca_1_3.yaml
    @5,5 interface_types["myinterfacetype1"].instantiate: unsupported keyname
    @32,9 node_types["mytype"].interfaces["myinterface0b"].instantiate: unsupported keyname
    @47,9 node_types["mytype"].interfaces["myinterface1b"].instantiate: unsupported keyname
    @62,9 node_types["mytype"].interfaces["myinterface2b"].instantiate: unsupported keyname
juan@BACVU2KFN0:~/myenvs/TOSCA/PT6_328/tests$

[tliron]

I've introduced a new quirk to address this: interfaces.operations.permissive. Note that it must support both syntax styles, because the internal TOSCA 1.3 profile is written in the new style. What this means is that the operations and notifications keynames are parsed as usual, however with this quirk any other keynames are parsed as extra operations.

I would I appreciate if you could built from HEAD locally and test to see if this addresses your request!

[tliron]

@jpc4242 Would you be able to test this to see if it works for you?

[jpc4242]

Yes, @tliron , I checked it and it works flawlessly. Thank you very much (and my apologies for not having seen your previous message)