...
4.1.4: Execution Monitoring
4.2: Participant Side
4.2.1: Participant Agent
...
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.
4.2.
...
1:
...
Participant
...
Message handling
Participant handles 4
...
types of messages
1. Participant State Change : This message handles states of a participant. Runtime can order participant for a state change.
ParticipantState can be set to one of the following
UNKNOWN : Control Loop execution is unknown.
PASSIVE : Control Loop execution is always rejected.
SAFE : Control Loop execution proceeds, but changes to domain state or context are not carried out.
The participant returns an indication that it is running in SAFE mode together with the action it would
have performed if it was operating in ACTIVE mode.
TEST : Control Loop execution proceeds and changes to domain and state are carried out in a test environment.
The participant returns an indication that it is running in TEST mode together with the action it has performed
on the test environment
ACTIVE : Control Loop execution is executed in the live environment by the participant.
TERMINATED : Control Loop execution is terminated and not available.
2. Control Loop Update: This message creates the control loop elements and brings them from UNINITIALISED to PASSIVE state.
ControlLoopUpdate message contains full ToscaServiceTemplate describing all components participanting 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.
UNINITIALISED : The control loop or control loop element should become uninitialised on participants, it should not exist on participants.
PASSIVE : The control loop or control loop element should initialised 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
UNINITIALISED : The control loop or control loop element is not initialised on participants, it does not exist on participants.
UNINITIALISED2PASSIVE : The control loop or control loop element is changing from unitialised to passive,
it is being initialised onto participants.
PASSIVE : The control loop or control loop element is initialised 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.
PASSIVE2UNINITIALISED : The control loop or control loop element is changing from passive to unitialised,
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 recieved Participant Status message and stores relavent information in database, Or performs respective actions.
4.2.2: Policy Participant Agent
Policy participant recieves messages through participant-intermediary common code, and handles them by invoking REST APIs towards policy-framework.
For example, When a ControlLoopUpdate message is recieved by policy participant, it contains full ToscaServiceTemplate describing all components
participating in a control loop. When the control loop element state changed from UNINITIALISED to PASSIVE, Policy-participant triggers creation
of policy-types and policies in Policy-Framework.
When the state changes from PASSIVE to UNINITIALISED, Policy-Participant deletes the policies, policy-types by invoking REST APIs towards policy-framework.
4.2.4: DCAE Participant Agent
DCAE participant recieves 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 recieved by DCAE participant, it contains full ToscaServiceTemplate describing all components
participating in a control loop. When the control loop element state changed from UNINITIALISED to PASSIVE, DCAE-participant triggers deploy
of DCAE.
When the state changes from PASSIVE to UNINITIALISED, DCAE-Participant undeployes DCAE by invoking methods towards CLAMP.
4.2.5: Kubernates Participant Agent
Kubernates participant recieves messages through participant-intermediary common code, and handles them by invoking Kubernetes Open API.
For example, When a ControlLoopUpdate message is recieved by Kubernates participant, When the control loop element state changed from UNINITIALISED to PASSIVE, Kubernates-participant triggers Kubernetes Open API and passes the HELM charts towards cluster.
4.3: Client Side
4.3.1: Client SDK: Composition of Control Loop Tosca
...