diff options
Diffstat (limited to 'docs/clamp/acm/design-impl/participants')
6 files changed, 101 insertions, 101 deletions
diff --git a/docs/clamp/acm/design-impl/participants/http-participant.rst b/docs/clamp/acm/design-impl/participants/http-participant.rst index b4b9b858..be0349ea 100644 --- a/docs/clamp/acm/design-impl/participants/http-participant.rst +++ b/docs/clamp/acm/design-impl/participants/http-participant.rst @@ -1,6 +1,6 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. _clamp-controlloop-http-participant: +.. _clamp-acm-http-participant: HTTP Participant ################ @@ -8,7 +8,7 @@ HTTP Participant The CLAMP HTTP participant receives configuration information from the CLAMP runtime, maps the configuration information to a REST URL, and makes a REST call on the URL. Typically the HTTP Participant is used with another participant such as the -:ref:`Kubernetes Participant <clamp-controlloop-k8s-participant>`, which brings up +:ref:`Kubernetes Participant <clamp-acm-k8s-participant>`, which brings up the microservice that runs a REST server. Once the microservice is up, the HTTP participant can be used to configure the microservice over its REST interface.Of course, the HTTP participant works towards any REST service, it is not restricted to REST @@ -18,31 +18,31 @@ services started by participants. .. image:: ../../images/participants/http-participant.png -The HTTP participant runs a Control Loop Element to handle the REST dialogues for a +The HTTP participant runs a Automation Composition Element to handle the REST dialogues for a particular application domain. The REST dialogues are whatever REST calls that are required to implement the functionality for the application domain. -The HTTP participant allows the REST dialogues for a Control Loop to be managed. A -particular Control Loop may require many *things* to be configured and managed and this +The HTTP participant allows the REST dialogues for a Automation Composition to be managed. A +particular Automation Composition may require many *things* to be configured and managed and this may require many REST dialogues to achieve. -When a control loop is initialized, the HTTP participant starts a HTTP Control Loop -element for the control loop. It reads the configuration information sent from the -Control Loop Runtime runs a HTTP client to talk to the REST endpoint that is receiving -the REST requests. A HTTP participant can simultaneously manage HTTP Control Loop +When a automation composition is initialized, the HTTP participant starts a HTTP Automation Composition +element for the automation composition. It reads the configuration information sent from the +Automation Composition Runtime runs a HTTP client to talk to the REST endpoint that is receiving +the REST requests. A HTTP participant can simultaneously manage HTTP Automation Composition Elements towards multiple REST endpoints, as shown in the diagram above where the HTTP -participant is running two HTTP Control Loop Elements, one for Control Loop A and one for -Control Loop B. +participant is running two HTTP Automation Composition Elements, one for Automation Composition A and one for +Automation Composition B. -Configuring a Control Loop Element on the HTTP participant for a Control Loop +Configuring a Automation Composition Element on the HTTP participant for a Automation Composition ----------------------------------------------------------------------------- A *Configuration Entity* describes a concept that is managed by the HTTP participant. A Configuration Entity can be created, Read, Updated, and Deleted (CRUD). The user defines -the Configuration Entities that it wants its HTTP Control Loop Element to manage and +the Configuration Entities that it wants its HTTP Automation Composition Element to manage and provides a sequence of parameterized REST commands to Create, Read, Update, and Delete each Configuration Entity. -Sample tosca template defining a http participant and a control loop element for a control loop. :download:`click here <tosca/tosca-http-participant.yml>` +Sample tosca template defining a http participant and a automation composition element for a automation composition. :download:`click here <tosca/tosca-http-participant.yml>` The user configures the following properties in the TOSCA for the HTTP participant: @@ -62,7 +62,7 @@ The user configures the following properties in the TOSCA for the HTTP participa * - configurationEntitiies - map - A map of *<String, ConfigurationEntity>* describing the names and definitions of - configuration entities that are managed by this HTTP Control Loop Element + configuration entities that are managed by this HTTP Automation Composition Element The *ConfigurationEntity* type is described in the following table: @@ -104,30 +104,30 @@ The *RestRequest* type is described in the following table: Http participant Interactions: ------------------------------ -The http participant interacts with Control Loop Runtime on the northbound via DMaap. It interacts with any microservice on the southbound over http for configuration. +The http participant interacts with Automation Composition Runtime on the northbound via DMaap. It interacts with any microservice on the southbound over http for configuration. -The communication for the Control loop updates and state change requests are sent from the Control Loop Runtime to the participant via DMaap. -The participant invokes the appropriate http endpoint of the microservice based on the received messages from the Control Loop Runtime. +The communication for the Automation Composition updates and state change requests are sent from the Automation Composition Runtime to the participant via DMaap. +The participant invokes the appropriate http endpoint of the microservice based on the received messages from the Automation Composition Runtime. startPhase: ----------- -The http participant is often used along with :ref:`Kubernetes Participant <clamp-controlloop-k8s-participant>` to configure the microservice after the deployment. -This requires the Control Loop Element of http participant to be started after the completion of deployment of the microservice. This can be achieved by adding the property `startPhase` -in the Control Loop Element of http participant. Control Loop Runtime starts the elements based on the `startPhase` value defined in the Tosca. The default value of startPhase is taken as '0' -which takes precedence over the Control Loop Elements with the startPhase value '1'. Http Control Loop Elements are defined with value '1' in order to start the Control Loop Element in the second phase. +The http participant is often used along with :ref:`Kubernetes Participant <clamp-acm-k8s-participant>` to configure the microservice after the deployment. +This requires the Automation Composition Element of http participant to be started after the completion of deployment of the microservice. This can be achieved by adding the property `startPhase` +in the Automation Composition Element of http participant. Automation Composition Runtime starts the elements based on the `startPhase` value defined in the Tosca. The default value of startPhase is taken as '0' +which takes precedence over the Automation Composition Elements with the startPhase value '1'. Http Automation Composition Elements are defined with value '1' in order to start the Automation Composition Element in the second phase. Http participant Workflow: -------------------------- -Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Control Loop Runtime to register this participant on the runtime database. -The user can commission the tosca definitions from the Policy Gui to the Control Loop Runtime that further updates the participant with these definitions via DMaap. -Once the control loop definitions are available in the runtime database, the Control Loop can be instantiated with the default state "UNINITIALISED" from the Policy Gui. +Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Automation Composition Runtime to register this participant on the runtime database. +The user can commission the tosca definitions from the Policy Gui to the Automation Composition Runtime that further updates the participant with these definitions via DMaap. +Once the automation composition definitions are available in the runtime database, the Automation Composition can be instantiated with the default state "UNINITIALISED" from the Policy Gui. -When the state of the Control Loop is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the http participant receives the control loop state change event from the runtime and -configures the microservice of the corresponding Control Loop Element over http. -The configuration entity for a microservice is associated with each Control Loop Element for the http participant. +When the state of the Automation Composition is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the http participant receives the automation composition state change event from the runtime and +configures the microservice of the corresponding Automation Composition Element over http. +The configuration entity for a microservice is associated with each Automation Composition Element for the http participant. The http participant holds the executed http requests information along with the responses received. The participant is used in a generic way to configure any entity over http and it does not hold the information about the microservice to unconfigure/revert the configurations when the -state of Control Loop changes from "PASSIVE" to "UNINITIALISED". +state of Automation Composition changes from "PASSIVE" to "UNINITIALISED". diff --git a/docs/clamp/acm/design-impl/participants/k8s-participant.rst b/docs/clamp/acm/design-impl/participants/k8s-participant.rst index 20f60b60..9de18070 100644 --- a/docs/clamp/acm/design-impl/participants/k8s-participant.rst +++ b/docs/clamp/acm/design-impl/participants/k8s-participant.rst @@ -1,6 +1,6 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. _clamp-controlloop-k8s-participant: +.. _clamp-acm-k8s-participant: Kubernetes Participant ###################### @@ -38,12 +38,12 @@ Defining a TOSCA CL definition for kubernetes participant: ---------------------------------------------------------- A *chart* parameter map describes the helm chart parameters in tosca template for a microservice that is used by the kubernetes participant for the deployment. -A Control Loop element in TOSCA is mapped to the kubernetes participant and also holds the helm chart parameters for a microservice defined under the properties of the Control Loop Element. +A Automation Composition element in TOSCA is mapped to the kubernetes participant and also holds the helm chart parameters for a microservice defined under the properties of the Automation Composition Element. -Sample tosca template defining a participant and a control loop element for a control loop. :download:`click here <tosca/tosca-k8s-participant.yml>` +Sample tosca template defining a participant and a automation composition element for a automation composition. :download:`click here <tosca/tosca-k8s-participant.yml>` -Configuring a Control Loop Element on the kubernetes participant for a Control Loop +Configuring a Automation Composition Element on the kubernetes participant for a Automation Composition ----------------------------------------------------------------------------------- The user configures the following properties in the TOSCA template for the kubernetes participant: @@ -105,27 +105,27 @@ The *repository* type is described in the following table: Kubernetes participant Interactions: ------------------------------------ -The kubernetes participant interacts with Control Loop Runtime on the northbound via DMaap. It interacts with the helm client on the southbound for performing various helm operations to the k8s cluster. +The kubernetes participant interacts with Automation Composition Runtime on the northbound via DMaap. It interacts with the helm client on the southbound for performing various helm operations to the k8s cluster. -The communication for the Control loop updates and state change requests are sent from the Control Loop Runtime to the participant via DMaap. -The participant performs appropriate operations on the k8s cluster via helm client based on the received messages from the Control Loop Runtime. +The communication for the Automation Composition updates and state change requests are sent from the Automation Composition Runtime to the participant via DMaap. +The participant performs appropriate operations on the k8s cluster via helm client based on the received messages from the Automation Composition Runtime. kubernetes participant Workflow: -------------------------------- -Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Control Loop Runtime to register this participant on the runtime database. -The user can commission the tosca definitions from the Policy Gui to the Control Loop Runtime that further updates the participant with these definitions via DMaap. -Once the control loop definitions are available in the runtime database, the Control Loop can be instantiated with the default state "UNINITIALISED" from the Policy Gui. +Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Automation Composition Runtime to register this participant on the runtime database. +The user can commission the tosca definitions from the Policy Gui to the Automation Composition Runtime that further updates the participant with these definitions via DMaap. +Once the automation composition definitions are available in the runtime database, the Automation Composition can be instantiated with the default state "UNINITIALISED" from the Policy Gui. -When the state of the Control Loop is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the kubernetes participant receives the control loop state change event from the runtime and -deploys the helm charts associated with each Control Loop Elements by creating appropriate namespace on the cluster. +When the state of the Automation Composition is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the kubernetes participant receives the automation composition state change event from the runtime and +deploys the helm charts associated with each Automation Composition Elements by creating appropriate namespace on the cluster. If the repository of the helm chart is not passed via TOSCA, the participant looks for the helm chart in the configured helm repositories of helm client. It also performs a chart look up on the local chart database where the helm charts are onboarded via the participant's REST Api. The participant also monitors the deployed pods for the next 3 minutes until the pods comes to RUNNING state. It holds the deployment information of the pods including the current status of the pods after the deployment. -When the state of the Control Loop is changed from "PASSIVE" to "UNINITIALISED" back, the participant also undeploys the helm charts from the cluster that are part of the Control Loop Element. +When the state of the Automation Composition is changed from "PASSIVE" to "UNINITIALISED" back, the participant also undeploys the helm charts from the cluster that are part of the Automation Composition Element. REST APIs on Kubernetes participant ----------------------------------- diff --git a/docs/clamp/acm/design-impl/participants/participant-intermediary.rst b/docs/clamp/acm/design-impl/participants/participant-intermediary.rst index a483dfc3..95c1a7ac 100644 --- a/docs/clamp/acm/design-impl/participants/participant-intermediary.rst +++ b/docs/clamp/acm/design-impl/participants/participant-intermediary.rst @@ -1,6 +1,6 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. _clamp-controlloop-participant-intermediary: +.. _clamp-clamp-acm-participant-intermediary: Participant Intermediary ######################## @@ -8,7 +8,7 @@ Participant Intermediary The CLAMP Participant Intermediary is a common library in ONAP, which does common message and state handling for participant implementations. It provides a Java API, which participant implementations implement to receive and send messages to the CLAMP runtime and to handle -Control Loop Element state. +Automation Composition Element state. Terminology ----------- @@ -19,20 +19,20 @@ Terminology Inbound messages to participants -------------------------------- -- PARTICIPANT_REGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantRegister message sent from a participant -- PARTICIPANT_DEREGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantDeregister message sent from a participant -- CONTROL_LOOP_STATE_CHANGE: a message received from controlloop runtime server for a state change of controlloop -- CONTROL_LOOP_UPDATE: a message received from controlloop runtime server for a controlloop update with controlloop instances -- PARTICIPANT_UPDATE: a message received from controlloop runtime server for a participant update with tosca definitions of controlloop -- PARTICIPANT_STATUS_REQ: A status request received from controlloop runtime server to send an immediate ParticipantStatus from all participants +- PARTICIPANT_REGISTER_ACK: received as a response from clamp-acm runtime server as an acknowledgement to ParticipantRegister message sent from a participant +- PARTICIPANT_DEREGISTER_ACK: received as a response from clamp-acm runtime server as an acknowledgement to ParticipantDeregister message sent from a participant +- AUTOMATION_COMPOSITION_STATE_CHANGE: a message received from clamp-acm runtime server for a state change of clamp-acm +- AUTOMATION_COMPOSITION_UPDATE: a message received from clamp-acm runtime server for a clamp-acm update with clamp-acm instances +- PARTICIPANT_UPDATE: a message received from clamp-acm runtime server for a participant update with tosca definitions of clamp-acm +- PARTICIPANT_STATUS_REQ: A status request received from clamp-acm runtime server to send an immediate ParticipantStatus from all participants Outbound messages ----------------- - PARTICIPANT_REGISTER: is sent by a participant during startup - PARTICIPANT_DEREGISTER: is sent by a participant during shutdown - PARTICIPANT_STATUS: is sent by a participant as heartbeat with the status and health of a participant -- CONTROLLOOP_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopStateChange -- CONTROLLOOP_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopUpdate +- AUTOMATIONCOMPOSITION_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionStateChange +- AUTOMATIONCOMPOSITION_UPDATE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionUpdate - PARTICIPANT_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ParticipantUpdate Design of a PARTICIPANT_REGISTER message @@ -57,59 +57,59 @@ Design of a PARTICIPANT_DEREGISTER message - It triggers the execution to send a PARTICIPANT_DEREGISTER_ACK message to the participant registered - Participant is not monitored. -Design of a creation of a Control Loop Type +Design of a creation of an Automation Composition Type ------------------------------------------- - If there are participants registered with CL-runtime, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message - the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) - Participant-intermediary will receive a PARTICIPANT_UDPATE message and stores the Tosca Service Template data on ParticipantHandler -Design of a deletion of a Control Loop Type +Design of a deletion of an Automation Composition Type ------------------------------------------- - if there are participants registered, CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message - the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition -- It deletes the Control Loop Type from DB +- It deletes the Automation Composition Type from DB - Participant-intermediary will receive a PARTICIPANT_UDPATE message and deletes the Tosca Service Template data on ParticipantHandler -Design of a creation of a Control Loop +Design of a creation of an Automation Composition -------------------------------------- -- CONTROL_LOOP_UPDATE message with instantiation details and UNINITIALISED state is sent to participants +- AUTOMATION_COMPOSITION_UPDATE message with instantiation details and UNINITIALISED state is sent to participants - Participant-intermediary validates the current state change -- Participant-intermediary will recieve CONTROL_LOOP_UPDATE message and sends the details of ControlLoopElements to participants +- Participant-intermediary will recieve AUTOMATION_COMPOSITION_UPDATE message and sends the details of AutomationCompositionElements to participants - Each participant performs its designated job of deployment by interacting with respective frameworks -Design of a deletion of a Control Loop +Design of a deletion of an Automation Composition -------------------------------------- -- CONTROL_LOOP_STATE_CHANGE message with UNINITIALISED state is sent to participants +- AUTOMATION_COMPOSITION_STATE_CHANGE message with UNINITIALISED state is sent to participants - Participant-intermediary validates the current state change -- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of ControlLoopElements to participants +- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of AutomationCompositionElements to participants - Each participant performs its designated job of undeployment by interacting with respective frameworks -Design of "issues control loop commands to control loops" - case UNINITIALISED to PASSIVE +Design of "issues automation composition commands to automation compositions" - case UNINITIALISED to PASSIVE ----------------------------------------------------------------------------------------- -- CONTROL_LOOP_STATE_CHANGE message with state changed from UNINITIALISED to PASSIVE is sent to participants +- AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from UNINITIALISED to PASSIVE is sent to participants - Participant-intermediary validates the current state change -- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants - Each participant performs its designated job of state change by interacting with respective frameworks -Design of "issues control loop commands to control loops" - case PASSIVE to UNINITIALISED +Design of "issues automation composition commands to automation compositions" - case PASSIVE to UNINITIALISED ----------------------------------------------------------------------------------------- -- CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to UNINITIALISED is sent to participants +- AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from PASSIVE to UNINITIALISED is sent to participants - Participant-intermediary validates the current state change -- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants - Each participant performs its designated job of state change by interacting with respective frameworks -Design of "issues control loop commands to control loops" - case PASSIVE to RUNNING +Design of "issues automation composition commands to automation compositions" - case PASSIVE to RUNNING ----------------------------------------------------------------------------------- -- CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to RUNNING is sent to participants +- AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from PASSIVE to RUNNING is sent to participants - Participant-intermediary validates the current state change -- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants - Each participant performs its designated job of state change by interacting with respective frameworks -Design of "issues control loop commands to control loops" - case RUNNING to PASSIVE +Design of "issues automation composition commands to automation compositions" - case RUNNING to PASSIVE ----------------------------------------------------------------------------------- -- CONTROL_LOOP_STATE_CHANGE message with state changed from RUNNING to PASSIVE is sent to participants +- AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from RUNNING to PASSIVE is sent to participants - Participant-intermediary validates the current state change -- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants - Each participant performs its designated job of state change by interacting with respective frameworks Design of a PARTICIPANT_STATUS message @@ -118,12 +118,12 @@ Design of a PARTICIPANT_STATUS message - This message will hold the state and healthStatus of all the participants running actively - PARTICIPANT_STATUS message holds a special attribute to return Tosca definitions, this attribute is populated only in response to PARTICIPANT_STATUS_REQ -Design of a CONTROLLOOP_UPDATE_ACK message +Design of a AUTOMATIONCOMPOSITION_UPDATE_ACK message ------------------------------------------ -- A participant sends CONTROLLOOP_UPDATE_ACK message in response to a CONTROLLOOP_UPDATE message. -- For each CL-elements moved to the ordered state as indicated by the CONTROLLOOP_UPDATE -- ControlLoopUpdateAckListener in CL-runtime collects the messages from DMaap -- It checks the status of all control loop elements and checks if the control loop is primed -- It updates the controlloop in DB accordingly +- A participant sends AUTOMATIONCOMPOSITION_UPDATE_ACK message in response to a AUTOMATIONCOMPOSITION_UPDATE message. +- For each CL-elements moved to the ordered state as indicated by the AUTOMATIONCOMPOSITION_UPDATE +- AutomationCompositionUpdateAckListener in CL-runtime collects the messages from DMaap +- It checks the status of all automation composition elements and checks if the automation composition is primed +- It updates the clamp-acm in DB accordingly -Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK +Design of a AUTOMATIONCOMPOSITION_STATECHANGE_ACK is similar to the design for AUTOMATIONCOMPOSITION_UPDATE_ACK diff --git a/docs/clamp/acm/design-impl/participants/participant-simulator.rst b/docs/clamp/acm/design-impl/participants/participant-simulator.rst index 9ac4e735..a53e9077 100644 --- a/docs/clamp/acm/design-impl/participants/participant-simulator.rst +++ b/docs/clamp/acm/design-impl/participants/participant-simulator.rst @@ -1,14 +1,14 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. _clamp-controlloop-participant-simulator: +.. _clamp-acm-participant-simulator: Participant Simulator ##################### This can be used for simulation testing purpose when there are no actual frameworks or a full deployment. -Participant simulator can edit the states of ControlLoopElements and Participants for verification of other controlloop components +Participant simulator can edit the states of AutomationCompositionElements and Participants for verification of other clamp-acm components for early testing. -All controlloop components should be setup, except participant frameworks (for example, no policy framework components +All clamp-acm components should be setup, except participant frameworks (for example, no policy framework components are needed) and participant simulator acts as respective participant framework, and state changes can be done with following REST APIs Participant Simulator API diff --git a/docs/clamp/acm/design-impl/participants/participants.rst b/docs/clamp/acm/design-impl/participants/participants.rst index 230c9888..15aee04d 100644 --- a/docs/clamp/acm/design-impl/participants/participants.rst +++ b/docs/clamp/acm/design-impl/participants/participants.rst @@ -5,21 +5,21 @@ Control Loop Participants ######################### -A Participant is a component that acts as a bridge between the CLAMP COntrol Loop runtime and components such as -the Policy Framework, DCAE, or a Kubernetes cluster that are taking part in control loops. It listens +A Participant is a component that acts as a bridge between the CLAMP Automation Composition Management runtime and components such as +the Policy Framework, DCAE, or a Kubernetes cluster that are taking part in automation composition management. It listens to DMaaP to receive messages from the CLAMP runtime and performs operations towards components that -are taking part in control loops. A participant has a Control Loop Element for each control loop in +are taking part in acms. A participant has an Automation Composition Management Element for each automation composition in which it is taking part. The implementation of a participant may use a common -:ref:`Participant Intermediary library <clamp-controlloop-participant-intermediary>`, which carries out common -message and state handling for Control Loop Elements in participants. The *ParticipantImpelementation* is the +:ref:`Participant Intermediary library <clamp-acm-participant-intermediary>`, which carries out common +message and state handling for Automation Composition Elements in participants. The *ParticipantImpelementation* is the component specific implementation of a participant, which is specifically developed for each component that -wishes to take part in control loops. +wishes to take part in automation composition management. .. image:: ../../images/participants/participants.png -The figure above shows participants for various components that may take part in control loops. +The figure above shows participants for various components that may take part in automation composition management. .. note:: The figure above is for illustration. Not all the participants mentioned above have realizations in ONAP. Some of the participants in the figure above represent diff --git a/docs/clamp/acm/design-impl/participants/policy-framework-participant.rst b/docs/clamp/acm/design-impl/participants/policy-framework-participant.rst index 56b2844f..1ef38b3e 100644 --- a/docs/clamp/acm/design-impl/participants/policy-framework-participant.rst +++ b/docs/clamp/acm/design-impl/participants/policy-framework-participant.rst @@ -1,6 +1,6 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. _clamp-controlloop-policy-framework-participant: +.. _clamp-acm-policy-framework-participant: The CLAMP Policy Framework Participant ###################################### @@ -8,11 +8,11 @@ The CLAMP Policy Framework Participant .. contents:: :depth: 3 -Control Loop Elements in the Policy Framework Participant are configured using TOSCA metadata defined for the Policy Control Loop Element type. +Automation Composition Elements in the Policy Framework Participant are configured using TOSCA metadata defined for the Policy Automation Composition Element type. The Policy Framework participant receives messages through participant-intermediary common code, and handles them by invoking REST APIs towards policy-framework. -For example, When a ControlLoopUpdate message is received by policy participant, it contains full ToscaServiceTemplate describing all components participating in a control loop. When the control loop element state changed from UNINITIALIZED to PASSIVE, the Policy-participant triggers the creation of policy-types and policies in Policy-Framework. +For example, When a AutomationCompositionUpdate message is received by policy participant, it contains full ToscaServiceTemplate describing all components participating in an automation composition. When the automation composition element state changed from UNINITIALIZED to PASSIVE, the Policy-participant triggers the creation of policy-types and policies in Policy-Framework. When the state changes from PASSIVE to UNINITIALIZED, Policy-Participant deletes the policies, policy-types by invoking REST APIs towards the policy-framework. @@ -31,9 +31,9 @@ Distributing Policies The Policy Framework participant uses the Policy PAP API to deploy and undeploy policies. -When a Policy Framework Control Loop Element changes from state PASSIVE to state RUNNING, the policy is deployed. When it changes from state RUNNING to state PASSIVE, the policy is undeployed. +When a Policy Framework Automation Composition Element changes from state UNINITIALISED to state PASSIVE, the policy is deployed. When it changes from state PASSIVE to state UNINITIALISED, the policy is undeployed. -The PDP group to which the policy should be deployed is specified in the Control Loop Element metadata, see the Policy Control Loop Element type definition. If the PDP group specified for policy deployment does not exist, an error is reported. +The PDP group to which the policy should be deployed is specified in the Automation Composition Element metadata, see the Policy Automation Composition Element type definition. If the PDP group specified for policy deployment does not exist, an error is reported. The PAP Policy Status API and Policy Deployment Status API are used to retrieve data to report on the deployment status of policies in Participant Status messages. @@ -42,19 +42,19 @@ The PDP Statistics API is used to get statistics for statistics report from the Policy Type and Policy References +++++++++++++++++++++++++++++++++ -The Policy Framework uses the policyType and policyId properties defined in the Policy Control Loop Element type references to specify what policy type and policy should be used by a Policy Control Loop Element. +The Policy Framework uses the policyType and policyId properties defined in the Policy Automation Composition Element type references to specify what policy type and policy should be used by a Policy Automation Composition Element. -The Policy Type and Policy specified in the policyType and policyId reference must of course be available in the Policy Framework in order for them to be used in Control Loop instances. In some cases, the Policy Type and/or the Policy may be already loaded in the Policy Framework. In other cases, the Policy Framework participant must load the Policy Type and/or policy. +The Policy Type and Policy specified in the policyType and policyId reference must of course be available in the Policy Framework in order for them to be used in Automation Composition instances. In some cases, the Policy Type and/or the Policy may be already loaded in the Policy Framework. In other cases, the Policy Framework participant must load the Policy Type and/or policy. Policy Type References ********************** The Policy Participant uses the following steps for Policy Type References: -#. The Policy Participant reads the Policy Type ID from the policyType property specified for the Control Loop Element. +#. The Policy Participant reads the Policy Type ID from the policyType property specified for the Automation Composition Element. #. It checks if a Policy Type with that Policy Type ID has been specified in the ToscaServiceTemplateFragment field in - the ControLoopElement definition in the ControlLoopUpdate message, see :ref:`controlloop-participant-protocol-label`. + the AutomationCompositionElement definition in the AutomationCompositionUpdate message, see :ref:`clampacm-participant-protocol-label`. #. If the Policy Type has been specified, the Participant stores the Policy Type in the Policy framework. If the Policy Type is successfully stored, execution proceeds, otherwise an error is reported. @@ -67,10 +67,10 @@ Policy References The Policy Participant uses the following steps for Policy References: -#. The Policy Participant reads the Policy ID from the policyId property specified for the Control Loop Element. +#. The Policy Participant reads the Policy ID from the policyId property specified for the Automation Composition Element. #. It checks if a Policy with that Policy ID has been specified in the ToscaServiceTemplateFragment field in the - ControLoopElement definition in the ControlLoopUpdate message, :ref:`controlloop-participant-protocol-label`. + AutomationCompositionElement definition in the AutomationCompositionUpdate message, :ref:`clampacm-participant-protocol-label`. #. If the Policy has been specified, the Participant stores the Policy in the Policy framework. If the Policy is successfully stored, execution proceeds, otherwise an error is reported. |