diff options
Diffstat (limited to 'docs/clamp/acm')
12 files changed, 276 insertions, 273 deletions
diff --git a/docs/clamp/acm/defining-acms.rst b/docs/clamp/acm/defining-acms.rst new file mode 100644 index 00000000..185f53a8 --- /dev/null +++ b/docs/clamp/acm/defining-acms.rst @@ -0,0 +1,273 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. + +.. _defining-acms-label: + +Defining Automation Compositions in TOSCA for CLAMP +################################################### + + +.. contents:: + :depth: 4 + + +A Automation Composition Type is defined in a TOSCA service template. A TOSCA Service Template has +two parts: a definition part in the service template itself, which contains the definitions +of concepts that can be used to define the types of concepts that can appear on a Toplogy +Template and a Topology Template that defines a topology. See the `Oasis Open TOSCA +<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/>`_ web page +for more details on TOSCA. + +Unsurprisingly, to define a Automation Composition Type in TOSCA, of Automation Composition related concepts +that we can use in all automation compositions exist. They are described in Section 1. Section 2 +describes how properties are managed. Properties are the configuration parameters that are +provided to Automation Compositions and the Automation Composition Elements they use. Section 3 describes how to +define a Automation Composition using the predefined Automation Composition concepts. + + +1 Standard TOSCA Service Template Concepts for Automation Compositions +====================================================================== + +These concepts are the base concepts available to users who write definitions for automation +compositions in TOSCA. TOSCA automation composition definitions are written using these concepts. + +1.1 Fundamental TOSCA Concepts for Automation Compositions +---------------------------------------------------------- + +The following TOSCA concepts are the fundamental concepts in a TOSCA Service Template for +defining automation compositions. + +.. image:: images/defining-acms/fundamental-concepts.png + +The TOSCA concepts above may be declared in the TOSCA Service Template of a automation composition. +If the concepts already exist in the Design Time Catalogue or the Runtime Inventory, they +may be omitted from a TOSCA service template that defines a automation composition type. + +The *start_phase* is a value indicating the start phase in which this automation composition element +will be started, the first start phase is zero. Automation Composition Elements are started in their +start_phase order and stopped in reverse start phase order. Automation Composition Elements with the +same start phase are started and stopped simultaneously. + +The Yaml file that holds the Definition of `TOSCA fundamental Automation Composition Types is available in Github +<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/AutomationCompositionTOSCAServiceTemplateTypes.yaml>`_ +and is the canonical definition of the Automation Composition concepts. + +1.2 TOSCA Concepts for Automation Composition Elements delivered by ONAP +------------------------------------------------------------------------ + +TOSCA Standard Automation Composition Elements + +.. image:: images/defining-acms/standard-acme.png + :width: 600 + +1.2.1 Policy Automation Composition Element +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Policy Participant runs Policy Automation Composition Elements. Each Policy Automation Composition Element +manages the deployment of the policy specified in the Policy Automation Composition Element definition. +The Yaml file that holds the `Policy Automation Composition Element Type definition is available in Github +<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyAutomationCompositionElementType.yaml>`_ +and is the canonical definition of the Policy Automation Composition Element type. For a description of +the Policy Automation Composition Element and Policy Participant, please see `The CLAMP Policy Framework +Participant <#>`_ page. + +1.2.2 HTTP Automation Composition Element +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The HTTP Participant runs HTTP Automation Composition Elements. Each HTTP Automation Composition Element manages +REST communication towards a REST endpoint using the REST calls a user has specified in the +configuration of the HTTP Automation Composition Element. The Yaml file that holds the +`HTTP Automation Composition Element Type definition is available in Github +<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyAutomationCompositionElementType.yaml>`_ +and is the canonical definition of the HTTP Automation Composition Element type. For a description of +the HTTP Automation Composition Element and HTTP Participant, please see `The CLAMP HTTP Participant <#>`_ page. + +.. _kubernetes-acm-element: + +1.2.3 Kubernetes Automation Composition Element +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Kubernetes Participant runs Kubernetes Automation Composition Elements. Each Kubernetes Automation Composition +Element manages a Kubernetes microservice using Helm. The user defines the Helm chart for the +Kubernetes microservice as well as other properties that the microservice requires in order to +execute. The Yaml file that holds the +`Kubernetes Automation Composition Element Type defintion is available in Github +<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/KubernetesAutomationCompositionElementType.yaml>`_ +and is the canonical definition of the Kubernetes Automation Composition Element type. For a description +of the Kubernetes Automation Composition Element and Kubernetes Participant,please see +`The CLAMP Kubernetes Participant <#>`_ page. + + +2 Common and Instance Specific Properties +========================================= + +Properties are used to define the configuration for Automation Compositions and Automation Composition Elements. +At design time, the types, constraints, and descriptions of the properties are specified. +The values for properties are specified in the CLAMP GUI at runtime. TOSCA provides support +for defining properties, see `Section 3.6.10: TOSCA Property Definition +<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#DEFN_ELEMENT_PROPERTY_DEFN>`_ +in the TOSCA documentation. + +2.1 Terminology for Properties +------------------------------ + +**Property:** Metadata defined in TOSCA that is associated with a Automation Composition, a Automation +Composition Element, or a Participant. + +**TOSCA Property Type:** The TOSCA definition of the type of a property. A property can have +a generic type such as string or integer or can have a user defined TOSCA data type. + +**TOSCA Property Value:** The value of a Property Type. Property values are assigned at run +time in CLAMP. + +**Common Property Type:** Property Types that apply to all instances of a Automation Composition Type. + +**Common Property Value:** The value of a Property Type. It is assigned at run time once for +all instances of a Automation Composition Type. + +**Instance Specific Property Type:** Property Types that apply to an individual instance of +a Automation Composition Type. + +**Instance Specific Property Value:** The value of a Property Type that applies to an +individual instance of a Automation Composition Type. The value is assigned at run time for each +automation composition instance. + +Automation Composition Properties can be *common* or *instance specific*. See Section 2 of +:ref:`TOSCA Defined Automation Compositions: Architecture and Design <acm-capabilities>` +for a detailed description of the usage of common and instance specific properties. + +2.2 Common Properties +--------------------- + +Common properties apply to all instances of a automation composition. Common properties are identified +by a special metadata flag in Automation Composition and Automation Composition Element definitions. For example, +the startPhase parameter on any Automation Composition Element has the same value for any instance of +that automation composition element, so it is defined as shown below in the +`Definition of TOSCA fundamental Automation Composition Types +<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/AutomationCompositionTOSCAServiceTemplateTypes.yaml>`_ +yaml file. + +.. code-block:: yaml + + startPhase: + type: integer + required: false + constraints: + - greater-or-equal: 0 + description: A value indicating the start phase in which this automation composition element will be started, the + first start phase is zero. Automation Composition Elements are started in their start_phase order and stopped + in reverse start phase order. Automation Composition Elements with the same start phase are started and + stopped simultaneously + metadata: + common: true + +The "common: true" value in the metadata of the startPhase property identifies that property +as being a common property. This property will be set on the CLAMP GUI during automation composition +commissioning. + +2.3 Instance Specific Properties +-------------------------------- + +Instance Specific properties apply to individual instances of a Automation Composition and/or Automation +Composition Element and must be set individually for Automation Composition and Automation Composition Element instance. +Properties are instance specific by default, but can be identified by a special metadata flag +in Automation Composition and Automation Composition Element definitions. For example, the chart parameter on a +Kubernetes Automation Composition Element has a different value for every instance of a Kubernetes Automation +Composition Element, so it can be defined as shown below in the :ref:`Kubernetes Automation Composition Type definition +<kubernetes-acm-element>` yaml file. + + +.. code-block:: yaml + + # Definition that omits the common flag metadata + chart: + type: org.onap.datatypes.policy.clamp.acm.kubernetesAutomationCompositionElement.Chart + typeVersion: 1.0.0 + description: The helm chart for the microservice + required: true + + # Definition that specifies the common flag metadata + chart: + type: org.onap.datatypes.policy.clamp.acm.kubernetesAutomationCompositionElement.Chart + typeVersion: 1.0.0 + description: The helm chart for the microservice + required: true + metadata: + common: false + +The "common: false" value in the metadata of the chart property identifies that property as +being an instance specific property. This property will be set on the CLAMP GUI during automation +composition instantiation. + + +3 Writing a Automation Composition Type Definition +================================================== + +The TOSCA definition of a automation composition contains a TOSCA Node Template for the automation composition +itself, which contains TOSCA Node Templates for each Automation Composition Element that makes up the +Automation Composition. + +.. image:: images/defining-acms/acm-node-template.png + :width: 600 + +To create a automation composition, a user creates a TOSCA Topology Template. In the Topology Template, +the user creates a TOSCA Node Template for each Automation Composition Element that will be in the +Automation Composition Definition. Finally, the user creates the Node Template that defines the Automation +Composition itself, and references the Automation Composition Element definitions that make up the Automation Composition +Definition. + +3.1 The Gentle Guidance Automation Composition +---------------------------------------------- + +The best way to explain how to create a Automation Composition Definition is by example. + +.. image:: images/defining-acms/gentle-guidance-acm.png + +The example Gentle Guidance automation composition is illustrated in the diagram above. The domain logic for the automation composition is +implemented in a microservice running in Kubernetes, a policy, and some configuration that is passed to the microservice +over a REST endpoint. We want to manage the life cycle of the domain logic for our Gentle Guidance automation composition using +our TOSCA based Automation Composition Life Cycle Management approach. To do this we create four Automation Composition Element definitions, +one for the Kubernetes microservice, one for the policy and one or the REST configuration. + +3.2 The TOSCA Automation Composition Definition +----------------------------------------------- + +We use a TOSCA Topology Template to specify a Automation Composition definition and the definitions of +its Automation Composition Elements. Optionally, we can specify default parameter values in the TOSCA +Topology Template. The actual values of Automation Composition common and instance specific parameters +are set at run time in the CLAMP GUI. + +In the case of the Gentle Guidance automation composition, we define a Automation Composition Element Node Template +for each part of the domain logic we are managing. We then define the Automation Composition Node Template +for the automation composition itself. + +Please refer to the `No Properties yaml file in Github +<https://github.com/onap/policy-clamp/blob/cbd4d5dbe88928d5765e9749987f6b93f2b347e9/examples/src/main/resources/clamp/acm/gentleguidance/GentleGuidanceNoProperties.yaml>`_ +for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance +domain when no parameters are defined. + +Please refer to the `Default Properties yaml file in Github +<https://github.com/onap/policy-clamp/blob/cbd4d5dbe88928d5765e9749987f6b93f2b347e9/examples/src/main/resources/clamp/acm/gentleguidance/GentleGuidanceDefaultProperties.yaml>`_ +for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance +domain when the default values of parameters are defined. + + +4 Creating Custom Automation Composition Elements +================================================= + +Any organization can include their own component in the framework and use the framework and have +the Policy Framework CLAMP manage the lifecycle of domain logic in their component as part of a +Automation Composition. To do this, a participant for the component must be developed that allows Automation +Composition Elements for that component to be run. To develop a participant, the participant must comply +with the `CLAMP Participants <#>`_ +framework and in particular comply with `The CLAMP Automation Composition Participant Protocol <#>`_. +The organization must also specify a new Automation Composition Element type definition in TOSCA similar to +those supplied in ONAP and described in Section 1.2. This Automation Composition Element type tells the +CLAMP Automation Composition Lifecycle management that the Automation Composition Element exists and can be included +in automation compositions. It also specifies the properties that can be specified for the Automation Composition Element. + +An organization can supply the code for the Participant (for example as a Java jar file) and a +TOSCA artifact with the Automation Composition Element definition and it can be added to the platform. In +future releases, support will be provided to include participants and their Automation Composition Element +definitions as packaged plugins that can be installed on the platform. + +End of document diff --git a/docs/clamp/acm/defining-controlloops.rst b/docs/clamp/acm/defining-controlloops.rst deleted file mode 100644 index 92564c6f..00000000 --- a/docs/clamp/acm/defining-controlloops.rst +++ /dev/null @@ -1,273 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -.. _defining-controlloops-label: - -Defining Control Loops in TOSCA for CLAMP -######################################### - - -.. contents:: - :depth: 4 - - -A Control Loop Type is defined in a TOSCA service template. A TOSCA Service Template has -two parts: a definition part in the service template itself, which contains the definitions -of concepts that can be used to define the types of concepts that can appear on a Toplogy -Template and a Topology Template that defines a topology. See the `Oasis Open TOSCA -<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/>`_ web page -for more details on TOSCA. - -Unsurprisingly, to define a Control Loop Type in TOSCA, of Control Loop related concepts -that we can use in all control loops exist. They are described in Section 1. Section 2 -describes how properties are managed. Properties are the configuration parameters that are -provided to Control Loops and the Control Loop Elements they use. Section 3 describes how to -define a Control Loop using the predefined Control Loop concepts. - - -1 Standard TOSCA Service Template Concepts for Control Loops -============================================================ - -These concepts are the base concepts available to users who write definitions for control -loops in TOSCA. TOSCA control loop definitions are written using these concepts. - -1.1 Fundamental TOSCA Concepts for Control Loops ------------------------------------------------- - -The following TOSCA concepts are the fundamental concepts in a TOSCA Service Template for -defining control loops. - -.. image:: images/defining-controlloops/fundamental-concepts.png - -The TOSCA concepts above may be declared in the TOSCA Service Template of a control loop. -If the concepts already exist in the Design Time Catalogue or the Runtime Inventory, they -may be omitted from a TOSCA service template that defines a control loop type. - -The *start_phase* is a value indicating the start phase in which this control loop element -will be started, the first start phase is zero. Control Loop Elements are started in their -start_phase order and stopped in reverse start phase order. Control Loop Elements with the -same start phase are started and stopped simultaneously. - -The Yaml file that holds the Definition of `TOSCA fundamental Control Loop Types is available in Github -<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/ControlLoopTOSCAServiceTemplateTypes.yaml>`_ -and is the canonical definition of the Control Loop concepts. - -1.2 TOSCA Concepts for Control Loop Elements delivered by ONAP --------------------------------------------------------------- - -TOSCA Standard Control Loop Elements - -.. image:: images/defining-controlloops/standard-cle.png - :width: 600 - -1.2.1 Policy Control Loop Element -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Policy Participant runs Policy Control Loop Elements. Each Policy Control Loop Element -manages the deployment of the policy specified in the Policy Control Loop Element definition. -The Yaml file that holds the `Policy Control Loop Element Type definition is available in Github -<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyControlLoopElementType.yaml>`_ -and is the canonical definition of the Policy Control Loop Element type. For a description of -the Policy Control Loop Element and Policy Participant, please see `The CLAMP Policy Framework -Participant <#>`_ page. - -1.2.2 HTTP Control Loop Element -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The HTTP Participant runs HTTP Control Loop Elements. Each HTTP Control Loop Element manages -REST communication towards a REST endpoint using the REST calls a user has specified in the -configuration of the HTTP Control Loop Element. The Yaml file that holds the -`HTTP Control Loop Element Type definition is available in Github -<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/HttpControlLoopElementType.yaml>`_ -and is the canonical definition of the HTTP Control Loop Element type. For a description of -the HTTP Control Loop Element and HTTP Participant, please see `The CLAMP HTTP Participant <#>`_ page. - -.. _kubernetes-cl-element: - -1.2.3 Kubernetes Control Loop Element -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Kubernetes Participant runs Kubernetes Control Loop Elements. Each Kubernetes Control Loop -Element manages a Kubernetes microservice using Helm. The user defines the Helm chart for the -Kubernetes microservice as well as other properties that the microservice requires in order to -execute. The Yaml file that holds the -`Kubernetes Control Loop Element Type defintion is available in Github -<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/KubernetesControlLoopElementType.yaml>`_ -and is the canonical definition of the Kubernetes Control Loop Element type. For a description -of the Kubernetes Control Loop Element and Kubernetes Participant,please see -`The CLAMP Kubernetes Participant <#>`_ page. - - -2 Common and Instance Specific Properties -========================================= - -Properties are used to define the configuration for Control Loops and Control Loop Elements. -At design time, the types, constraints, and descriptions of the properties are specified. -The values for properties are specified in the CLAMP GUI at runtime. TOSCA provides support -for defining properties, see `Section 3.6.10: TOSCA Property Definition -<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#DEFN_ELEMENT_PROPERTY_DEFN>`_ -in the TOSCA documentation. - -2.1 Terminology for Properties ------------------------------- - -**Property:** Metadata defined in TOSCA that is associated with a Control Loop, a Control -Loop Element, or a Participant. - -**TOSCA Property Type:** The TOSCA definition of the type of a property. A property can have -a generic type such as string or integer or can have a user defined TOSCA data type. - -**TOSCA Property Value:** The value of a Property Type. Property values are assigned at run -time in CLAMP. - -**Common Property Type:** Property Types that apply to all instances of a Control Loop Type. - -**Common Property Value:** The value of a Property Type. It is assigned at run time once for -all instances of a Control Loop Type. - -**Instance Specific Property Type:** Property Types that apply to an individual instance of -a Control Loop Type. - -**Instance Specific Property Value:** The value of a Property Type that applies to an -individual instance of a Control Loop Type. The value is assigned at run time for each -control loop instance. - -Control Loop Properties can be *common* or *instance specific*. See Section 2 of -:ref:`TOSCA Defined Control Loops: Architecture and Design <controlloop-capabilities>` -for a detailed description of the usage of common and instance specific properties. - -2.2 Common Properties ---------------------- - -Common properties apply to all instances of a control loop. Common properties are identified -by a special metadata flag in Control Loop and Control Loop Element definitions. For example, -the startPhase parameter on any Control Loop Element has the same value for any instance of -that control loop element, so it is defined as shown below in the -`Definition of TOSCA fundamental Control Loop Types -<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/ControlLoopTOSCAServiceTemplateTypes.yaml>`_ -yaml file. - -.. code-block:: yaml - - startPhase: - type: integer - required: false - constraints: - - greater-or-equal: 0 - description: A value indicating the start phase in which this control loop element will be started, the - first start phase is zero. Control Loop Elements are started in their start_phase order and stopped - in reverse start phase order. Control Loop Elements with the same start phase are started and - stopped simultaneously - metadata: - common: true - -The "common: true" value in the metadata of the startPhase property identifies that property -as being a common property. This property will be set on the CLAMP GUI during control loop -commissioning. - -2.3 Instance Specific Properties --------------------------------- - -Instance Specific properties apply to individual instances of a Control Loop and/or Control -Loop Element and must be set individually for Control Loop and Control Loop Element instance. -Properties are instance specific by default, but can be identified by a special metadata flag -in Control Loop and Control Loop Element definitions. For example, the chart parameter on a -Kubernetes Control Loop Element has a different value for every instance of a Kubernetes Control -Loop Element, so it can be defined as shown below in the :ref:`Kubernetes Control Loop Type definition -<kubernetes-cl-element>` yaml file. - - -.. code-block:: yaml - - # Definition that omits the common flag metadata - chart: - type: org.onap.datatypes.policy.clamp.controlloop.kubernetesControlLoopElement.Chart - typeVersion: 1.0.0 - description: The helm chart for the microservice - required: true - - # Definition that specifies the common flag metadata - chart: - type: org.onap.datatypes.policy.clamp.controlloop.kubernetesControlLoopElement.Chart - typeVersion: 1.0.0 - description: The helm chart for the microservice - required: true - metadata: - common: false - -The "common: false" value in the metadata of the chart property identifies that property as -being an instance specific property. This property will be set on the CLAMP GUI during control -loop instantiation. - - -3 Writing a Control Loop Type Definition -========================================= - -The TOSCA definition of a control loop contains a TOSCA Node Template for the control loop -itself, which contains TOSCA Node Templates for each Control Loop Element that makes up the -Control Loop. - -.. image:: images/defining-controlloops/controlloop-node-template.png - :width: 600 - -To create a control loop, a user creates a TOSCA Topology Template. In the Topology Template, -the user creates a TOSCA Node Template for each Control Loop Element that will be in the -Control Loop Definition. Finally, the user creates the Node Template that defines the Control -Loop itself, and references the Control Loop Element definitions that make up the Control Loop -Definition. - -3.1 The Gentle Guidance Control Loop ------------------------------------- - -The best way to explain how to create a Control Loop Definition is by example. - -.. image:: images/defining-controlloops/gentle-guidance-controlloop.png - -The example Gentle Guidance control loop is illustrated in the diagram above. The domain logic for the control loop is -implemented in a microservice running in Kubernetes, a policy, and some configuration that is passed to the microservice -over a REST endpoint. We want to manage the life cycle of the domain logic for our Gentle Guidance control loop using -our TOSCA based Control Loop Life Cycle Management approach. To do this we create four Control Loop Element definitions, -one for the Kubernetes microservice, one for the policy and one or the REST configuration. - -3.2 The TOSCA Control Loop Definition -------------------------------------- - -We use a TOSCA Topology Template to specify a Control Loop definition and the definitions of -its Control Loop Elements. Optionally, we can specify default parameter values in the TOSCA -Topology Template. The actual values of Control Loop common and instance specific parameters -are set at run time in the CLAMP GUI. - -In the case of the Gentle Guidance control loop, we define a Control Loop Element Node Template -for each part of the domain logic we are managing. We then define the Control Loop Node Template -for the control loop itself. - -Please refer to the `No Properties yaml file in Github -<https://github.com/onap/policy-clamp/blob/master/common/src/test/resources/gentleguidance/GentleGuidanceNoPropeties.yaml>`_ -for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance -domain when no parameters are defined. - -Please refer to the `Default Properties yaml file in Github -<https://github.com/onap/policy-clamp/blob/master/common/src/test/resources/gentleguidance/GentleGuidanceDefaultPropeties.yaml>`_ -for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance -domain when the default values of parameters are defined. - - -4 Creating Custom Control Loop Elements -======================================== - -Any organization can include their own component in the framework and use the framework and have -the Policy Framework CLAMP manage the lifecycle of domain logic in their component as part of a -Control Loop. To do this, a participant for the component must be developed that allows Control -Loop Elements for that component to be run. To develop a participant, the participant must comply -with the `CLAMP Participants <#>`_ -framework and in particular comply with `The CLAMP Control Loop Participant Protocol <#>`_. -The organization must also specify a new Control Loop Element type definition in TOSCA similar to -those supplied in ONAP and described in Section 1.2. This Control Loop Element type tells the -CLAMP Control Loop Lifecycle management that the Control Loop Element exists and can be included -in control loops. It also specifies the properties that can be specified for the Control Loop Element. - -An organization can supply the code for the Participant (for example as a Java jar file) and a -TOSCA artifact with the Control Loop Element definition and it can be added to the platform. In -future releases, support will be provided to include participants and their Control Loop Element -definitions as packaged plugins that can be installed on the platform. - -End of document diff --git a/docs/clamp/acm/draw.io/acm-node-template.drawio b/docs/clamp/acm/draw.io/acm-node-template.drawio new file mode 100644 index 00000000..1a63737b --- /dev/null +++ b/docs/clamp/acm/draw.io/acm-node-template.drawio @@ -0,0 +1 @@ +<mxfile host="app.diagrams.net" modified="2022-04-05T12:49:40.502Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" etag="93W7hVhu2wOsYupjcs14" version="17.4.0" type="device"><diagram id="RYPNdAOSzT_k6u516NDZ" name="Page-1">7Zxbd5s4EIB/jR/jAxI3P+banm13N7tJN+3THmJkmwaQCzix8+srgQRIwi4mgJvEfvBBQgjQfJoZaSRG8Dxcf4jd5eJP7KFgBDRvPYIXIwAMRyP/NGOTZ+i2nWfMY99jWWXGjf+MWCa7br7yPZQIBVOMg9RfiplTHEVomgp5bhzjJ7HYDAfiXZfuHCkZN1M3UHPvfC9d5LkOsMv8j8ifL/iddWuSnwldXpi9SbJwPfxUyYKXI3geY5zmR+H6HAW07Xi75NddbTlbPFiMorTJBV9v9ZXxw/hi3f1/d/b97Mv9h2frBIK8mkc3WLE3vv375vyUZJ2uUkxewscRSZzjcIkTP09ZAbnh2X1Mjub06ALN/Iidy9403fDmIy+9pIerMLiK3ZAcnj0t/BTdLN0pzX8i0JC8RRoGJKWTwxivIg/RZ9ZIqmg0mpji0J+y48C9R8GZO32YZxec4wDH5FSEI3qPJI3xQyEwWu0MR+mVG/oB5fA/FHtu5LJsBp1Oq3UDfx6RxJQ0Korp0/I6bHp6wUUNaWrmB4F0Y1UoTE6PKE7RupLFhPQB4RCl8YYU4WdNBgzvMSz5VOJnGixvUUHP5AVdhvy8qLqkghwwMPaBBCqQKIJGkXdKuxttu8BNEiqoqlhJe8Sbr9XENybJLHGxFlIbnlr7Kb1IG5ss9Y1XQY7Li2iCX7NVBAlexVO04z1N1qlTN56jdEdBi9WIPEF5qCKtyqxOZCwvRgHpaI+iyqkTI7vDNfbJuxXEmJYtEAM1iYT8zdlVVRUhV6TpQkUmhKThharytlGqyrgqXvwFqNl7oYaXKJI540ZEB5kicOOUl/Z8N8SRd7vwI36KlzV4xpUfFFUR6d6w2+I4XeA5jtzgsswttEWAZlQP0j7uE9NxyrLvcUpUaBV+xvH++IMh+Dea8m825Z9xdSJiBTuhHjpAqNVw2kGvS/VAKPWevpF39kL+PsDTByJmz00WmZlk1DNwNbUP1GlhbWwLJOqNSaTNXqJ4oo01zdrJI01co9gn7UQt6m5G99GoutWN+oTAHuu2JRpdh76YPil+LeGCwBpLfOmGRm6nlT9jWNwmA+JW6i/NqVBD2jbTuB1B82vDrh2OrhOul7h6sVqiBAyFo0bgEEm6m0qxJS2Q9IEWf6BDG2+tkfFu41u2NeQvQBc0tcl2Q8ZfyHMxgOc8222dTVOsCMgVHZ5nXeE5VICOUeI/u/dZUhNx/oV7mOLl9oHsCMBZ9qsZpKo07eyObGqEPeOomJBoPiTl/ttLxyniBXg2S1AvNo5ryorg9PFYnZ1oILs4H629YuF1IzsuPNZZT4A2mDD3m304tH9sTeyqp/O6XWNzoo81S3GNWyr8iTgMbOrAdAaSMSBI9SP33Ti8wEtoavx7YEQZP7d1cA27awe32X0AFCbOyUFeY7fwmXvB91omtgrM7d9qgoqPuQ46QWXoImdmy35hSwM/a2C1aSnkfiS3BtrtZol2MbxPHKAcTv3KwArTCGZfoDkNQWs8EzpMJMCSUIFmS1ttTaSK5JBC39CpcQAWl5R4S578MHCz2FuFsszpZoWyyOHCD7zP7gavaHsTfTh94KmzBY79Z1Le5RcL+lPfEugrr7qhtbH7ZAMKdM2J04usz26S8mfBQeAuEz/36GmRkLSlH50xpZrHPdlrXVXuXB1V/GZR0q09rfkwRZ7OB2rY06npOMDZ3kdeFPQ01Gl5Hhn/C3uI6j8ULl3SXVUl2DOU24LPRyY7ZtIE0oilJhav18Xi5RBSd1Sqs/fb12nUW+ijxnwjdAJLGi85NXRyp3MQnWmqAYAddF4GKESZ03EITo9KdChMuevIDXsNpkADAypRU53Xl037Ecg3DCSU9GadVQdDWnUe5GumN7PllvWrLY+m/W0gamoNTLs9qGlXozAfb2+vR7vWCZcW/qhJ3ySmUMLU0OpMew2m/WnSdjGeyuS6NZKjPPXxQdAuPjgaYvqSd9aDrKaTmIC2FPZvvN7JmYzFoDOUV7h3FBACE9FDNfQBAkLmfgGhN0pqm5X0fZFqmK+PVGcIUtUA0Hsk9YBrSBVSJ6a8L+MVsGoOwaoaN2o0A8W2sA0/pjr6qgP5qoYp9qFiuWnVVwWD+qr7bfzoJ5z+e22sa+O49rmxTl7rLKvKxkubpKl66Ay7rc7cb9PHe0CtjT1/DaiZ8qojTfEVeoaNt2wFtmsc+NPNcbLoPRtgqEHRHzTqJovsAQ2wpcaBPq3uURyhFCVHWN83rNKIy9FVWGHdBLzZF6xAgTVfhplmsUoNz+hfxA8lLslrpyKTeXNLMpiJAr7KfnVNLK8IDn3Py1YO133dQ8SjC19eWsFdbNmujr31GmMt71ppI51HtH6++OePTw/h3b8zcB5epd9PT1RNssu/Uld3l00kTYlYhl11t+h+azadssPjoil5X0nphhmQb9jOHLGxBiY7nbG6XSpb90EU6833WaxeqarWKWu5iHfS0BU0tXrahvH8oDRPAtqu2S0MarGCsrc1u7V9QFVQ/FNBVGMLncH6scL8xEmSkUJXX+jacl2e5J8XCnk15KnymvL8LpQcy+pevynKrIbh7dYHiluu6r4BVKfeuvgCUK1o67bgdSHafFfme5OuJk7AAsvsS7okWX5gLO/n5Vfa4OVP</diagram></mxfile>
\ No newline at end of file diff --git a/docs/clamp/acm/draw.io/fundamental-concepts.drawio b/docs/clamp/acm/draw.io/fundamental-concepts.drawio new file mode 100644 index 00000000..b7adce27 --- /dev/null +++ b/docs/clamp/acm/draw.io/fundamental-concepts.drawio @@ -0,0 +1 @@ +<mxfile host="app.diagrams.net" modified="2022-04-05T09:12:37.309Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" version="17.4.0" etag="fA0oINVl5eVVmPUGOO6X" type="device"><diagram id="cbTz21U9R7ytQ8vLfwRy" name="Page-1">7Vvdc+I2EP9rmGkfksEyxvAYIGlvJm2vk0zbe7oRWGD1ZMu1RQL313dlS/6QTCAc5tKUewjWSlpLu7/90MrXc6fR5qcUJ+EvPCCsh/rBpufOegih/hDBj6RsC4qvCauUBgXJqQgP9CtRxL6irmlAssZAwTkTNGkSFzyOyUI0aDhN+XNz2JKz5lsTvCIW4WGBmU39kwYiLKgj5Ff0nwldhfrNznBc9ERYD1Y7yUIc8Ocayb3tudOUc1E8RZspYVJ4Wi7FvLsdveXCUhKLQyYEvz9tJvd/f/acafiBjaPsYzS5Usp4wmytNtxDQwb8JlmCY7lqsVWiGP6zlkudLHksrpY4ogxUetOTbx3iKIGeHnLdAfw+kTTAMbbocmz+N2eR5bqWDJx+sin75njxZZXydRxcLTjjaTEkXc1/QJ6Xv20Kf43nH6vlwdNK/j7+9jCVM2/WgoMuKJe7mfIo4RktWmp18TwrFlnsGwRYbL1g817EcQcccARQwSyXQ7wgich2bho19ooAu4l8XEfsLgU2MOY5pII8JHgh6c9g/EALRcSg5UixUMamxYJnMY/zGcp+UL63UFuN2y/fCJISZLMT305pNeBuCI+ISLcwRE8YqinK0wyU3T1XZjsYK1pYM1l3qIhYuYpVybqyJnhQBvUK43Jcy7o0Kn8FRwk/j1sQqyXsZxoxnIusLlAAyYMaJCW2CCkL7vGWr+U+MgE40a1JyFP6lee6LiZDdyqUc3Wcfrt+qlkPkpt6T0okMj9qNTgl6R5nQq+FM4aTjM7z1ckhEU5XNJ5wAcanBult3dXeDKawzP9JrhLkJNCjtbcs+Ed0oZ4ZnhM2Ka3C2EMmUv6l9NRabnfKPGd/KFNU4lQCkWwxo6sYGgvYJklPg0h30ESkM7Qh6aA2SHaGyIGFyN3+8YLOd43OgddEZ4m6OjqH50Sn35KMGOgjcXAjszpozRmXMJgEOAtzxUh5Qr/UoNIGtLQUUROvIKN0+5ccdu17uv2p3jnblExka6tbGyqKechTzU+1rmqWbOhJxTZIYKWahq5gq3ydLsgBFgwmsyJib/Cxtd+m3ZQw8ABPzdW1qVex+8gprLtEEqQsDSR5nttkUexKzaqnqAYjx2DkeuMmo2LXFqMcbeUev8E9eq9xj7eMyITqOzlK9+Inz+QnjSjutvhJ1G/xk93llUMLpjkyPichzmwgwtZFE4SFfA2ht2BJi5ORpSgOMoLC0fhGkQVPdhwEDBRAJ41X9zmXGTpULS+YqK0srZwDddNZDBudMYYdE4pqge9Vce+UIcx7eyFsZJwdHf+4COYfF8AAD3hbG5bIAdnu5Q5cI3cbNmo/8FBwPG10tPMzfZydYYEvB4Z3Hgid0Zs7ztreViNSVbjg6UMA+6NLCmI4MzTRBZlnQqZ/wFF2cNYUbdySBxS11oA+6TprLEupVQm21tMyGCSUFXXrvGeemmNNDm87DfS+LQ0cvZgGogP1P+hK/23q7zwN/G9lgaNDs0D/bFmgP2y4Ec8xsreD6xhGeuaMjILIq9PAU1c6tIHUAAqRB8ya4uS7lTQuqdy5AmY5pTyntDjMs56bHWQBMl3HgP2+DHkGDmvgM4PRXCl20uJeS09Z95PV4XmPq3TqjrLmN9/Qgbn2XUGb1q/6185o7DY0P7L0PjqRL91zEj7Yl3rHHakrRnogXy4z0k3d2LmE+z0Y1gFnf7jfkdl1cW9h3oD5R95bmIycsVE++v7x3kaoOilfQvz7DPGuEeJHdoQfnTPA23cWL7lInpDY8HtNj5iDSo8OKI54HDyGNDbxNtAE5VxzVuDQNJp5KkK+4jFmtxV134m3lmS0O9bKle67RfbrXlz7985vkctPKY8tweuMwojNJ3HLVsT3j0wdXGcPo66vk+1D1gXz5nXVG8T8joJDl5h3UbP04KAjL6DGRibiG0s50QWU9WnboP/istDL47u5sEL295evs79mVtDM0PcZ4+5k3rLVQ0H+YlLstQRz7zR5sud6DeVZZfNDwWkycs1so2OHjOzPHx9lVdwExbeXystMznSjEQ2C3N3ur5efIgk0PqhCLXWes37ih+wvrJzra7vCY2vgcMnmJwQ8Lw8rypcBX2/S82aS11rwTBngK5Rrpu0nUJCnbyC0glrSdLdFQagzBdl5evQ/1o7hrxxbO20X3kdoB5rVfwUq/F31H6rc238B</diagram></mxfile>
\ No newline at end of file diff --git a/docs/clamp/acm/draw.io/standard-acme.drawio b/docs/clamp/acm/draw.io/standard-acme.drawio new file mode 100644 index 00000000..f8f7f90d --- /dev/null +++ b/docs/clamp/acm/draw.io/standard-acme.drawio @@ -0,0 +1 @@ +<mxfile host="app.diagrams.net" modified="2022-04-05T09:14:50.017Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" etag="N8ksXkiLfCb-aaYhfdFz" version="17.4.0" type="device"><diagram id="2XpnY2_hXlSYiaPWDiV9" name="Page-1">7ZpRc+MmEIB/jR/PI5Al24+JE186TaeZsdtL+9LBFrZokNAhfLbv1xckkCUhO0pqpWnOeQksCwj2Y2HBPXcS7T5zlIS/sADTHnSCXc+96UEIHR/Kf0qyzyVDI1hzEuQicBDMyHeshY6WbkiA04qiYIwKklSFSxbHeCkqMsQ521bVVoxWe03QGluC2RJRW/qFBCLMpSM4PMjvMFmHpmfgj/OSCBllPZI0RAHblkTubc+dcMZEnop2E0zV5Jl5yetNj5QWH8ZxLNpUcPzt18fJzQI4f352pn/z+Z6IT7qVb4hu9IDnv84mV1I0EygOEA9k8mojmBwOYbHMTFiUsJTo3C3Fkew/1UMUezNvcrSJSm4iOuUoksnrbUgEniVoqeRbiYuUhSKiMgdkkrNNHGD1sY7MFbOlMksWkaVOU7TA9Botn9ZZhQmjjMuimMWqj1Rw9lRYSjW7YrGYoohQBeDvmAcoRlqsaQOqWUTJOpaZpRwN5uprTRu+Kg6NjV2VWxFKax3recRc4N1RA4HC7HK9YBZhwfdSxVTQTO3N2smz2wN2w7GWhSXkBo4WIo36umj5QINMaCBeAAe04OCbWJraUaav2btkSDUJRK6gKz2lCyYkP7IAx8GVWpJKRtnySYl2RDxqy6r0Hyrdh57O3uxKZTd7k4nl6B51b1kmr+aZ7KFaljP18o/GgbXiaxaSA2MbvsQnpsbXrgjxNRYn9EYnLe70pbuAVatbRh9p83JM5Rr8Vv32Jpvr7h4YkaMq+voEXE/OULkvAL1qK/mwdcWyK6m35T3bVD4zJ5oyimy1SnFFJ2O1mKzX4+ta+FrUNhEZm10I+Hl2SlS/GUElygsInZdBWBDf98rMnwT+jOCOW4I7bAa3xKVyjOcAE4JBDSY4eiWX7vDZpo5weS7mBm/EnHaRBjvwvqED4N1RB8bjOirua6lzqi4c+O2YkxSgfUktUQrp8U92/doBYeDVEM5bPCvQ3lsBPfxfAe2+O6D9YR3owfi1QI/qbrQt0ueizreoez4Gkan5XsYcViSyJRFF2SG9RF52/tdKWYgREhrcoz3bKHOmQgYYJncdMk6+S31kKstibqKHYwHBodJMNaa74TiV1R4McqAQ3aNUmE9hlKIkJYvs45RKJGebxNf6HJ3HR3pU01LPPeiusr/3F031/n14BL06lYbv0mqCDjRK5RjJ7ypEGlqgZmz8lYQotVGUgxdVDPMZrk17A01mQileiYYQS7DkSIBd40AWknh9n7VyA9sa5vgata21N5tiW9u4XdlmZNlGrjs5bQQl/5m3AODiLt7GXdh7GLDdBXAaLlTgqCMgxzaQjJLlvtUV22Vf+6CgQk+dfSsHe79hY4OgD99yZzMX8CVak4zWn4KPva+NX7yvHTFNZxsbsG/tf94sMI+xwOnFmfzQzmRYvSNwnQZXMmzY9ADojFb7GaEHfaqYCcg3mVyLDC1Ji5HLfkpFTdosXpF12lqf468bws1TVctKAkeJDMlx+xrZEAv1Ba+r1hv4yG4UHAH1hB9t4nLUGZb288DdfP5wcZ8/svv0Rn71JOY2uE/QgOm4M0ybXhQsx7NAKf6N09aOKhQiucMowLy9c8t97oZnK+M2FnJNXHxd2Ze8yNc1QdTdWd6+xT/h5C73Ih/ZxUHfeiNtuBcZNl7VdXYzAuwLf4vA0jMTS3DcO/LjoYIsoxwQFLE4mIckNkWlx6jq01Tp3QrWCR302j8hnXzx8RqWvneeRyDX8/r+0Cn+QMXQnlttr/V7kFfdFevvSh0/BgH7kj3qYD8pFll9R4lIEKhuWmwqZ1if9VdeY7TKrWVD/NbZ3mFfo4N+3/4B2McxgAlDtAFGoCsDyOzh55/5ajn8iNa9/Qc=</diagram></mxfile>
\ No newline at end of file diff --git a/docs/clamp/acm/images/defining-acms/acm-node-template.png b/docs/clamp/acm/images/defining-acms/acm-node-template.png Binary files differnew file mode 100644 index 00000000..707f189f --- /dev/null +++ b/docs/clamp/acm/images/defining-acms/acm-node-template.png diff --git a/docs/clamp/acm/images/defining-acms/fundamental-concepts.png b/docs/clamp/acm/images/defining-acms/fundamental-concepts.png Binary files differnew file mode 100644 index 00000000..f8a37bba --- /dev/null +++ b/docs/clamp/acm/images/defining-acms/fundamental-concepts.png diff --git a/docs/clamp/acm/images/defining-controlloops/gentle-guidance-controlloop.png b/docs/clamp/acm/images/defining-acms/gentle-guidance-acm.png Binary files differindex 3e0862fb..3e0862fb 100644 --- a/docs/clamp/acm/images/defining-controlloops/gentle-guidance-controlloop.png +++ b/docs/clamp/acm/images/defining-acms/gentle-guidance-acm.png diff --git a/docs/clamp/acm/images/defining-acms/standard-acme.png b/docs/clamp/acm/images/defining-acms/standard-acme.png Binary files differnew file mode 100644 index 00000000..6ab0ce2b --- /dev/null +++ b/docs/clamp/acm/images/defining-acms/standard-acme.png diff --git a/docs/clamp/acm/images/defining-controlloops/controlloop-node-template.png b/docs/clamp/acm/images/defining-controlloops/controlloop-node-template.png Binary files differdeleted file mode 100644 index e3e12538..00000000 --- a/docs/clamp/acm/images/defining-controlloops/controlloop-node-template.png +++ /dev/null diff --git a/docs/clamp/acm/images/defining-controlloops/fundamental-concepts.png b/docs/clamp/acm/images/defining-controlloops/fundamental-concepts.png Binary files differdeleted file mode 100644 index dc52a840..00000000 --- a/docs/clamp/acm/images/defining-controlloops/fundamental-concepts.png +++ /dev/null diff --git a/docs/clamp/acm/images/defining-controlloops/standard-cle.png b/docs/clamp/acm/images/defining-controlloops/standard-cle.png Binary files differdeleted file mode 100644 index d23f89ab..00000000 --- a/docs/clamp/acm/images/defining-controlloops/standard-cle.png +++ /dev/null |
