Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

To be update....    

Broadcast message: a message for all participants (participantId=null and participantType=null).
Message to a participant: a message only for a participant (participantId and participantType properly filled).
    
Design of a creation of a Control Loop Type

  • Gui calls POST "/commission" endpoint with a Control Loop Type Definition (Tosca Service Template) as body
  • it saves to DB the Tosca Service Template using PolicyModelsProvider
  • if there are participants registered, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message
  • message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition).

Design of a deletion of a Control Loop Type

  • GUI calls DELETE "/commission" endpoint
  • if there are participants registered, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message
  • message is built by ParticipantUpdatePublisher with a empty list of ParticipantDefinition
  • delete the Control Loop Type from DB

Design of a creation of a Control Loop

  • GUI calls POST "/instantiation" endpoint with a Control Loop as body
  • it validates the Control Loop
  • it saves the Control Loop to DB

Design of an update of a Control Loop

  • GUI calls PUT "/instantiation" endpoint with a Control Loop as body
  • it validates the Control Loop
  • it save the Control Loop to DB

Design of a deletion of a Control Loop

  • GUI calls DELETE "/instantiation" endpoint
  • it checks that Control Loop is in UNINITIALISED status
  • it deletes the Control Loop from DB

Design of a issues control loop commands to control loops - case UNINITIALISED to PASSIVE

  • GUI calls "/instantiation/command" endpoint with PASSIVE as orderedState
  • it checks if participants registered are matching with the list of control Loop Element
  • it updates control loop and control loop elements to DB (orderedState = PASSIVE)
  • it validates the status order issued
  • it triggers the execution to send a broadcast CONTROL_LOOP_UPDATE message
  • the message is built by ControlLoopUpdatePublisher using Tosca Service Template data and ControlLoop data. (with startPhase = 0)
  • it updates control loop and control loop elements to DB (state = UNINITIALISED2PASSIVE)

Design of a issues control loop commands to control loops - case PASSIVE to UNINITIALISED

  • GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState
  • it checks if participants registered are matching with the list of control Loop Element
  • it updates control loop and control loop elements to DB (orderedState = UNINITIALISED)
  • it validates the status order issued
  • it triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message
  • the message is built by ControlLoopStateChangePublisher with controlLoopId
  • it updates control loop and control loop elements to DB (state = PASSIVE2UNINITIALISED)

Design of a issues control loop commands to control loops - case PASSIVE to RUNNING

  • GUI calls "/instantiation/command" with RUNNING as orderedState
  • check if participants registered are matching with the list of control Loop Element.
  • update control loop and control loop elements to DB (orderedState = RUNNING)
  • validate the status order issued
  • trigger to ControlLoopStateChangePublisher to send a broadcast CONTROL_LOOP_STATE_CHANGE message
  • message is built by ControlLoopStateChangePublisher with controlLoopId
  • update control loop and control loop elements to DB (state = PASSIVE2RUNNING)

Design of a issues control loop commands to control loops - case RUNNING to PASSIVE

  • CALL /instantiation/command with UNINITIALISED as orderedState
  • check if participants registered are matching with the list of control Loop Element.
  • update control loop and control loop elements to db (orderedState = RUNNING)
  • validate the status order issued
  • trigger to ControlLoopStateChangePublisher to send a broadcast CONTROL_LOOP_STATE_CHANGE message
  • message is built by ControlLoopStateChangePublisher with controlLoopId
  • update control loop and control loop elements to db (state = RUNNING2PASSIVE)

StartPhase

The startPhase is particularly important in control loop update and control loop state changes because sometime the user wishes to control the order in which the state changes in Control Loop Elements in a control loop.

StartPhase is defined as shown below in the Definition of TOSCA fundamental Control Loop Types yaml file.

Control Loop Types yaml file
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.
Example where it could be used:

Control Loop Types yaml file
    org.onap.domain.database.Http_PMSHMicroserviceControlLoopElement:
      # Consul http config for PMSH.
      version: 1.2.3
      type: org.onap.policy.clamp.controlloop.HttpControlLoopElement
      type_version: 1.0.1
      description: Control loop element for the http requests of PMSH microservice
      properties:
        provider: ONAP
        participant_id:
          name: HttpParticipant0
          version: 1.0.0
        participantType:
          name: org.onap.k8s.controlloop.HttpControlLoopParticipant
          version: 2.3.4
        uninitializedToPassiveTimeout: 180
        startPhase: 1

In state changes from UNITITIALISED → PASSIVE, control loop elements are started in increasing order of their startPhase.

Example with Http_PMSHMicroserviceControlLoopElement with startPhase to 1 and PMSH_K8SMicroserviceControlLoopElement with startPhase to 0

  • CL-runtime sends CONTROL_LOOP_UPDATE message to all participants with startPhase = 0
  • participant receives the CONTROL_LOOP_UPDATE message and runs to PASSIVE state (only CL elements defined as startPhase = 0)
  • CL-runtime receives CONTROL_LOOP_UPDATE_ACT messages from participants and set the state (from the CL element of the message) to PASSIVE
  • CL-runtime calculates that all CL elements with startPhase = 0 are set to proper state and sends CONTROL_LOOP_UPDATE message to all participants with startPhase = 1
  • participant receives the CONTROL_LOOP_UPDATE message and runs to PASSIVE state (only CL elements defined as startPhase = 1)
  • CL-runtime calculates that all CL elements are set to proper state and set CL to PASSIVE

In that scenario the message CONTROL_LOOP_UPDATE has been sent two times.


SupervisionAspect

  • ThreadPoolExecutor: in this context is configured to execute task in ordered manner, one by one.
  • Scheduling: is used to schedule retry task.
  • MessageIntercept: is used to intercept messages from participants

Design of a PARTICIPANT_REGISTER message

  • the message is collected by ParticipantRegisterListener
  • the participant is save to db if not present with status UNKNOWN
  • if is present a Control Loop Type, it triggers to ParticipantUpdatePublisher to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming).
  • message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition).
  • trigger to ParticipantRegisterAckPublisher to send a PARTICIPANT_REGISTER_ACK message to the participant registered
  • from MessageIntercept the event is intercepted and if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner
  • in SupervisionScanner start the monitoring for participantUpdate  

Design of a PARTICIPANT_UPDATE_ACK message

Participants sends PARTICIPANT_UPDATE_ACK messages in response to a PARTICIPANT_UPDATE message.

  • the message is collected by ParticipantUpdateAckListener
  • from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner
  • in SupervisionScanner remove the monitoring for participantUpdate
  • update the status of the participant to db    

Design of a PARTICIPANT_STATUS message

  • the message is collected by ParticipantStatusListener
  • from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_STATUS in SupervisionScanner
  • in SupervisionScanner clear and start the monitoring for participantStatus

Design of a CONTROLLOOP_UPDATE_ACK message

Participants sends CONTROLLOOP_UPDATE_ACK messages in response to a CONTROLLOOP_UPDATE  message. It will send a CONTROLLOOP_UPDATE_ACK for each CL-elements moved to the state as indicated by the CONTROLLOOP_UPDATE.

  • the message is collected by ControlLoopUpdateAckListener
  • from the control loop into the message check the status of all control loop element and check if the control loop is primed
  • update the CL into the db if it is changed
  • from MessageIntercept the event is intercepted and it add a task to handle a monitoring execution in SupervisionScanner

Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK

Design of monitoring execution in SupervisionScanner

Monitoring is designed to process the follow operations:

  • determination of the next startPhase in a CONTROLLOOP_UPDATE message. 
  • upgrade CL state: in a scenario that CL state are in kind of transitional state (example UNINITIALISED2PASSIVE), if all CL-elements are moved properly to the specific state, the CL state will be upgrade to that.
  • retry CONTROLLOOP_UPDATE/CONTROL_LOOP_STATE_CHANGE messages. if there is a CL Element not in the proper state, will be retry a broadcast message.
  • retry PARTICIPANT_UPDATE message to the participant in a scenario that CL-runtime do not receive PARTICIPANT_UPDATE_ACT from it.
  • send PARTICIPANT_STATUS_REQ to the participant in a scenario that CL-runtime do not receive PARTICIPANT_STATUS from it, 

The solution Design of retry, timeout, and reporting for all Participant message dialogues are implemented into the monitoring execution.

  • Spring Scheduling start the task to monitor retry execution any heartBeatMs milliseconds
  • task is executed under the ThreadPoolExecutor
  • a message will be retry if do no receive Act message before MaxWaitMs milliseconds


This page is Work in Progress

This page is not updated for Istanbul, the information below this point may or may not be correct for Istanbul.

  • No labels