OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TCIcon indicating the project type

OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Uploaded image for project: 'OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC'
  1. OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
  2. TOSCA-111

Adding a dependsOn relation should not require changes to the type definition of the target

    Details

    • Type: Bug
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: CSD2
    • Fix Version/s: CSD2
    • Component/s: Interop
    • Labels:
      None
    • Proposal:
      Hide

      The syntax of the dependsOn RelationshipType can be changed so that the target end of the relation references a NodeType instead of a CapabilityType. This syntax is already supported in the current version of TOSCA. It is just a matter of writing the normative definition of dependsOn in this way. The result is that any NodeType can dependOn any other without having to change the type definition of the target NodeType.

      Show
      The syntax of the dependsOn RelationshipType can be changed so that the target end of the relation references a NodeType instead of a CapabilityType. This syntax is already supported in the current version of TOSCA. It is just a matter of writing the normative definition of dependsOn in this way. The result is that any NodeType can dependOn any other without having to change the type definition of the target NodeType.

      Description

      Current examples show the dependsOn RelationionshipType defined with a RequirementType on the source end and and CapabilityType on the remote end. This syntax forces someone wanting to use a dependsOn relation in a Service Template to have to a add a capability to the target NodeType if it does not yet have one, resulting in a change in the target's NodeType definition. In addition to being convenient and unnecessary, the "owner" of the target type may not expect users to be changing his/her type when they use it in Service Templates. From a type evolution perspective, this causes a change in the target NodeType, making it a different version than it original definition, which is not the intention (the user is not trying to change any of the semantics of the target NodeType).

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          travis.tripp Travis Tripp (Inactive) added a comment -

          It seems like it should allow either Node Type of capability type.

          I have been looking at similar things and have come across situations where I'd like to intermix Requirement \ Capability Type with Node Types in the source and target. Why does the spec say that you can't do that?

          Show
          travis.tripp Travis Tripp (Inactive) added a comment - It seems like it should allow either Node Type of capability type. I have been looking at similar things and have come across situations where I'd like to intermix Requirement \ Capability Type with Node Types in the source and target. Why does the spec say that you can't do that?
          Hide
          Permalink
          thomas.spatzier Thomas Spatzier (Inactive) added a comment -

          The spec has been written that way because at that time we thought it would be best to keep it symmetric, i.e. when you depend on a capability, you have a requirement OR it is two nodes that depend on each other. We can of course discuss to relax this.

          I think Derek's original proposal would go in this direction.

          @Derek: in the call where you presented this, I think you had an even crisper formulation of the proposal. Do you remember it?
          Wouldn't it make sense to remove source/target type restrictions from DependsOn completely?

          Show
          thomas.spatzier Thomas Spatzier (Inactive) added a comment - The spec has been written that way because at that time we thought it would be best to keep it symmetric, i.e. when you depend on a capability, you have a requirement OR it is two nodes that depend on each other. We can of course discuss to relax this. I think Derek's original proposal would go in this direction. @Derek: in the call where you presented this, I think you had an even crisper formulation of the proposal. Do you remember it? Wouldn't it make sense to remove source/target type restrictions from DependsOn completely?

            People

            • Assignee:
              Unassigned
              Reporter:
              dpalma Derek Palma (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: