The CLAMP Automation Composition Participant protocol is an asynchronous protocol that is used by the CLAMP runtime to coordinate lifecycle management of Automation Composition instances. The protocol supports the functions described in the sections below.

Protocol Dialogues

The protocol supports the dialogues described below.

Participant Registration and De-Registration

Registration when a participant comes up and update of participant with Automation Composition type information and common parameter values for its Automation Composition types.

@startuml
activate Participant
Participant -> Participant: Start Participant
deactivate Participant
Participant -> CLAMP_Runtime: Participant Registration
Participant <- CLAMP_Runtime: Participant Registration Ack
activate CLAMP_Runtime
loop over Automation Composition Type Definitions
	CLAMP_Runtime -> CLAMP_Runtime: Collect Automation Composition Element Type Definitions and\nCommon Property Values for\nParticipant Type of this Participant
end
deactivate CLAMP_Runtime
Participant <- CLAMP_Runtime: Participant Update\n[Automation Composition Element Type Definitions and\nCommon Property Values for\nParticipant Type of Participant]
activate Participant
Participant -> Participant: Store Automation Composition Element Type Definitions and\nCommon Property Values
Participant -> CLAMP_Runtime: Participant Update Ack
deactivate Participant

De-registration is executed as a participant goes down.

@startuml
Participant -> CLAMP_Runtime: Participant Deregistration
Participant <- CLAMP_Runtime: Participant Deregistration Ack
Participant -> Participant: Shutdown Participant

Automation Composition Priming and De-Priming

When an Automation Composition is primed, the portion of the Automation Composition Type Definition and Common Property values for the participants of each participant type mentioned in the Automation Composition Definition are sent to the participants.

@startuml
Commissioning_REST -> CLAMP_Runtime: Prime Automation Composition Type Defintions and\nset values of Common Properties
activate CLAMP_Runtime
loop over Participant Types in Automation Composition Type Definition
	CLAMP_Runtime -> CLAMP_Runtime: Collect Automation Composition Element Type Definitions and\nCommon Property Values for Participant Type
end
Participant <- CLAMP_Runtime: Participant Update\n[Automation Composition Element Type Definitions and\nCommon Property Values for Participant Types]
deactivate CLAMP_Runtime
activate Participant
Participant -> Participant: Store Automation Composition Element Type Definitions and\nCommon Property Values
Participant -> CLAMP_Runtime: Participant Update Ack\n[from each Participant mentioned in Participant Update message]
deactivate Participant

When an Automation Composition is de-primed, the portion of the Automation Composition Type Definition and Common Property values for the participants of each participant type mentioned in the Automation Composition Definition are deleted on participants.

@startuml
Commissioning_REST -> CLAMP_Runtime: De-Prime Automation Composition Type Definition
alt Automation Composition Instances exist for Automation Composition Type
	Commissioning_REST <- CLAMP_Runtime: Cannot decommission Automation Composition Type Definition
else No Automation Composition Instances exist for Automation Composition Type
	Participant <- CLAMP_Runtime: Participant Update\n[Remove Automation Composition Element Definitions\nfrom Participants in Automation Composition]
	activate Participant
	Participant -> Participant: Delete Automation Composition Element\nType Definitions and\nCommon Property Values
	Participant -> CLAMP_Runtime: Participant Update Ack [from each Participant mentioned in Participant Update message]
	deactivate Participant
end

Automation Composition Update

Automation Composition Update handles creation, change, and deletion of Automation Compositions on participants. Change of Automation Compositions uses a semantic versioning approach and follows the semantics described on the page TOSCA Defined Automation Compositions: Architecture and Design#4.1ACMVersionManagement.

@startuml
Participant <- CLAMP_Runtime: Automation Composition Update\n[to all Participants in Automation Composition]
Participant -> CLAMP_Runtime: Automation Composition Update Ack [from each Participant in Automation Composition]

The handling of an ACMUpdate message in each participant is as shown below.

@startuml

(*) --> "Process Update Message"

if "All Automation Composition Elements with my Participant ID processed?" then
  --> [yes] "Send Update Ack Message"
  --> (*)
else
  --> [no] "Process next Automation Composition Element with my ID"
  if "New Automation Composition Element?" then
	--> [yes] "Create Automation Composition Element"
	--> "Set Automation Composition Element to state UNINITIALISED"
	--> "Order Initiation of Automation Composition Element"
	--> "Pass Parameters to Automation Composition Element"
	--> "Wait for Initiation to complete"
	if "Automation Composition Element Initiation?" then
      --> [success] "Record Success for Update Ack message"
      --> "Process Update Message"
    else
      --> [fail] "Delete Automation Composition Element"
      --> "Record Error for Update Ack message"
      --> "Process Update Message"
    endif
  else
  	--> [no] "Check Automation Composition Element State"
  endif
  if "RUNNING and Automation Composition Version change != patch?" then
	--> [true] "Record Error for Update Ack message"
    --> "Process Update Message"
  else
  	[false] if "PASSIVE and Automation Composition Version change == major?" then
      --> [true] "Record Error for Update Ack message"
      --> "Process Update Message"
  else
	--> [false] "Pass Changed Parameters to Automation Composition Element"
	--> "Wait for reconfiguration to complete"
    if "Automation Composition Element Reconfiguration?" then
      --> [success] "Record Success for Update Ack message"
      --> "Process Update Message"
    else
      --> [fail] "Roll back reconfiguration"
      --> "Record Error for Update Ack message"
      --> "Process Update Message"
    endif
  endif
endif

@enduml

Automation Composition State Change

This dialogue is used to change the state of Automation Compositions and their Automation Composition Elements. the CLAMP Runtime sends an Automation Composition State Change message on the Automation Composition to all participants. Participants that have Automation Composition Elements in that Automation Composition attempt an update on the state of the Automation Composition elements they have for that Automation Composition, and report the result back.

The startPhase in the Definition of TOSCA fundamental Automation Composition Types is particularly important in Automation Composition state changes because sometimes the user wishes to control the order in which the state changes in Automation Composition Elements in an Automation Composition. In-state changes from UNITITIALISED → PASSIVE and from PASSIVE → RUNNING, Automation Composition elements are started in increasing order of their startPhase. In-state changes from RUNNING → PASSIVE and from PASSIVE → UNITITIALISED, Automation Composition elements are started in decreasing order of their startPhase.

The CLAMP runtime controls the state change process described in the diagram below. The CLAMP runtime sends an Automation Composition State Change message on DMaaP to all participants in a particular Start Phase so, in each state change multiple Automation Composition State Change messages are sent, one for each Start Phase in the Automation Composition. If more than one Automation Composition Element has the same Start Phase, those Automation Composition Elements receive the same Automation Composition State Change message from DMaaP and start in parallel.

The Participant reads each State Change Message it sees on DMaaP. If the Start Phase on the Automation Composition State Change message matches the Start Phase of the Automation Composition Element, the participant processes the State Change message. Otherwise, the participant ignores the message.

@startuml
activate CLAMP_Runtime
CLAMP_Runtime -> CLAMP_Runtime: Build an ordered list of the Start Phases in the Automation Composition Instance
deactivate CLAMP_Runtime

alt "State Change UNITIALISED_to_PASSIVE or PASSIVE_to_RUNNING"
  loop over Start Phases list in increasing order 
    CLAMP_Runtime -> Participant: Automation Composition State Change\n[to all Participants in Automation Composition with this Start Phase]
    CLAMP_Runtime -> CLAMP_Runtime: Asynchronously wait for answers from Participants
    CLAMP_Runtime <- Participant: Automation Composition State Change Ack [from each Participant in this Start Phase of Automation Composition]
    alt "State Change Ack reports success"
      CLAMP_Runtime -> CLAMP_Runtime: Log success
    else "State Change Ack reports an error"
      CLAMP_Runtime -> CLAMP_Runtime: Log error
      CLAMP_Runtime -> CLAMP_Runtime: Reset state of Automation Composition       CLAMP_Runtime -> CLAMP_Runtime: Abort State Change operation
    end 
  end
else "State Change RUNNING_to_PASSIVE or PASSIVE_to_UNITIALISED"
 loop over Start Phases list in decreasing order
    CLAMP_Runtime -> Participant: Automation Composition State Change\n[to all Participants in Automation Composition with this Start Phase]
    CLAMP_Runtime -> CLAMP_Runtime: Asynchronously wait for answers from Participants
    CLAMP_Runtime <- Participant: Automation Composition State Change Ack [from each Participant in this Start Phase of Automation Composition]
    alt "State Change Ack reports success"
      CLAMP_Runtime -> CLAMP_Runtime: Log success
    else "State Change Ack reports an error"
      CLAMP_Runtime -> CLAMP_Runtime: Log error
      CLAMP_Runtime -> CLAMP_Runtime: Reset state of Automation Composition       CLAMP_Runtime -> CLAMP_Runtime: Abort State Change operation
    end 
  end
end

CLAMP_Runtime -> CLAMP_Runtime: Set overall state of Automation Composition @enduml

The handling of an ACMStateChange message in each participant is as shown below.

@startuml

(*) --> "Process State Change Message"

if "All Automation Composition Elements with my Participant ID processed?" then
  --> [yes] "Send State Change Ack Message"
  --> (*)
else
  --> [no] "Process next Automation Composition Element with my ID"
  if "State Change Message Start Phase equals Automation Composition Element start phase" then
    [true] if "Current State is RUNNING?" then
      [true] if "Change to PASSIVE?" then
      --> [true] "Change Automation Composition Element to state PASSIVE"
      --> "Wait for RUNNING->PASSIVE State Change to complete"
      if "State Change?" then
        --> [success] "Record Success for State Change Ack message"
        --> "Process State Change Message"
      else
        --> [fail] "Record Error for State Change Ack message"
        --> "Process State Change Message"
      endif
      else
        --> [false] "Record Error for State Change Ack message"
        --> "Process State Change Message"
      endif
    else
      [false] if "Current State is PASSIVE?" then
        [true] if "Change to RUNNING?" then
          --> [true] "Change Automation Composition Element to state RUNNING"
          --> "Wait for PASSIVE->RUNNING State Change to complete"
          if "State Change?" then
            --> [success] "Record Success for State Change Ack message"
            --> "Process State Change Message"
          else
            --> [fail] "Record Error for State Change Ack message"
            --> "Process State Change Message"
          endif
        else
          --> [false] "Record Error for State Change Ack message"
          --> "Process State Change Message"
        endif
      else
        --> [false] "Record Error for State Change Ack message"
        --> "Process State Change Message"
      endif
    endif
  else
    --> [false] "Skip Automation Composition Element"
    --> "Process State Change Message"
endif

@enduml

Automation Composition Monitoring and Reporting

This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Automation Composition Elements, and to gather statistics on Automation Compositions. The ParticipantStatus message is sent periodically by each participant. The reporting interval for sending the message is configurable.

@startuml
Participant -> CLAMP_Runtime: Participant Status [periodically from each Participant in all Automation Compositions]

Messages

The CLAMP Automation Composition Participant Protocol uses the following messages. The descriptions below give an overview of each message. For the precise definition of the messages, see the CLAMP code at: https://github.com/onap/policy-clamp/tree/master/models/src/main/java/org/onap/policy/clamp/ACM/models/messages/dmaap/participant. All messages are carried on DMaaP.

Table of Contents

A Participant is a component that acts as a bridge between Runtime and components like Policy-framework, DCAE, Kubernetes cluster etc.
It listens to Dmaap to receive messages from runtime and performs operations towards control loop components.

Every participant has two parts Participant-Intermediary and a Participant-Impl.
Participant-Intermediary is a common component that listens to Dmaap and acts on the messages, participant-impl handles the logic towards
control loop element.

1: Participant Message handling

Participant handles 4 types of messages

...

2. Control Loop Update: This message creates the control loop elements and brings them from UNINITIALIZED to PASSIVE state.
    ControlLoopUpdate message contains full ToscaServiceTemplate describing all components participating in a control loop.
    This acts as a template for any control loop to be created according to the template.
    When participant-intermediary receives this message, it triggers creation of policy-types and policies in Policy-Framework by Policy-Participant,
    and deploys DCAE from DCAE-participant

3. Control Loop State change: This message is used to order a state change in control loop element.
    Runtime can order one of the following ordered states.
         UNINITIALIZED : The control loop or control loop element should become uninitialized on participants, it should not exist on participants.
         PASSIVE : The control loop or control loop element should initialized on the participants and be passive, that is,
                         it is not handling control loop messages yet.
         RUNNING : The control loop or control loop element should running and is executing control loops. Once any of above states are ordered, then control loop element transitions into
         UNINITIALIZED : The control loop or control loop element is not initialized on participants, it does not exist on participants.
         UNINITIALIZED2PASSIVE : The control loop or control loop element is changing from uninitialized to passive,
                         it is being initialized onto participants.
         PASSIVE : The control loop or control loop element is initialized on the participants but is passive, that is, it is not
                         handling control loop messages yet.
         PASSIVE2RUNNING : The control loop or control loop element is changing from passive to running,
                          the participants are preparing to execute control loops.
         RUNNING : The control loop or control loop element is running and is executing control loops.
         RUNNING2PASSIVE : The control loop or control loop element is completing execution of current control loops but
                          will not start running any more control loops and will become passive.
         PASSIVE2UNINITIALIZED : The control loop or control loop element is changing from passive to uninitialized,
                          the control loop is being removed from participants

4. Participant Healthcheck: This message is used to learn the health status of a participant.

As a response to any of the above message participant returns a Participant Status message, holding respective message response.
Runtime receives Participant Status message and stores relevant information in database, Or performs respective actions.

2: Policy Participant Agent

Policy 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, Policy-participant triggers 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 policy-framework.

3: DCAE Participant Agent

DCAE participant receives messages through participant-intermediary common code, and handles them by invoking CLAMP DCAE methods,
which internally work towards DCAE.

For example, When a ControlLoopUpdate message is received by DCAE participant, it contains full ToscaServiceTemplate describing all components
participating in a control loop. When the control loop element state changed from UNINITIALIZED to PASSIVE, DCAE-participant triggers deploy
of DCAE.
When the state changes from PASSIVE to UNINITIALIZED, DCAE-Participant un-deploys DCAE by invoking methods towards CLAMP.

4: Kubernetes Participant Agent

Kubernetes participant receives messages through participant-intermediary common code, and handles them by invoking Kubernetes Open API.
For example, When a ControlLoopUpdate message is received by Kubernetes participant, When the control loop element state changed from UNINITIALIZED to PASSIVE, Kubernetes-participant triggers Kubernetes Open API and passes the HELM charts towards cluster.

5: Participant Pass Through

For Control Loop Elements on certain participants, there may be a need to provide domain specific directives to a Control Loop Element or elements such as a microservice or a collection of microservices while a Control Loop Instance is running.

...