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-266

Creating an abstract or phantom node

    XMLWordPrintable

    Details

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

      In a perfect world we should have a TOSCA file for the monitoring server and we could reference to an external TOSCA file throug capabilities and boundary stuff, but .... very far from that goal so I believe that defining a property of the node (or something appropriate since there is still confusion on property and capabilities) that declare it as a node that the orchestrator does not have to install, but that it has to "find" and manage.
      In this way We could have some tools in the orchestrator that enable it to have the correct reference to that type of node (like a settings for management service) this will allow it to manage relations between nodes in a servicetemplate towards that "phantom" node.
      I use phantom since abstract is already taken, but I'm italian so I leave to english people to find the best suited english word to override with this meaning.

      Show
      In a perfect world we should have a TOSCA file for the monitoring server and we could reference to an external TOSCA file throug capabilities and boundary stuff, but .... very far from that goal so I believe that defining a property of the node (or something appropriate since there is still confusion on property and capabilities) that declare it as a node that the orchestrator does not have to install, but that it has to "find" and manage. In this way We could have some tools in the orchestrator that enable it to have the correct reference to that type of node (like a settings for management service) this will allow it to manage relations between nodes in a servicetemplate towards that "phantom" node. I use phantom since abstract is already taken, but I'm italian so I leave to english people to find the best suited english word to override with this meaning.

      Description

      In the standard we already have an abstract definition:
      "Node Types might be declared as abstract, meaning that they cannot be instantiated. The purpose of such abstract Node Types is to provide common properties and behavior for re-use in specialized, derived Node Types. Node Types might also be declared as final, meaning that they cannot be derived by other Node Types"
      This imply that in the topology we HAVE to substitute the abstract with a concrete implementation.
      We need to manage in the topology nodes that are not "created" in the service, but are there to have a reference for relations like central system like monitoring system or backup server; those system are not installed but we need to tell to the orchestrator "you have to add something to the monitoring server".

        Attachments

          Activity

            People

            • Assignee:
              luca.gioppo Luca Gioppo (Inactive)
              Reporter:
              luca.gioppo Luca Gioppo (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: