Page History

...

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

• CALL /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)

StartPhaseSupervisionAspect
        -

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.

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:

    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 CL update message to all participants with startPhase = 0
• participant receives the CL update message and starts the PASSIVE state
• CL-runtime receives CL update ACT messages from participants and set state of the PMSH_K8SMicroserviceControlLoopElement to PASIVE
• CL-runtime calculates that all CL elements with startPhase = 0 are set to proper state and sends CL update message to all participants with startPhase = 1

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

HandleCounter        -

• remove(id) -> used to remove from monitoring

...

• clear(id)  -> used to clear/start monitoring

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        -

• 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        -

• 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 message is similar to CONTROLLOOP_UPDATE_ACK
       

Solution Design of retry, timeout, and reporting for all Participant message dialogues

...

Design of startPhase into monitoring execution in SupervisionScanner        -

• phaseMap is map that contains (CL -> last startPhase sent)

...

• during the monitoring is calculate the the minimum startPhase where the status of a Element is not equal to the orderstatus (minSpNotCompleted).

...

• if the last startPhase sent is different to minSpNotCompleted and CL order status is UNINITIALISED2PASSIVE then send the CONTROLLOOP_UPDATE message with minSpNotCompleted as startPhase

Design of a monitoring execution in SupervisionScanner
        - for each CL
            - check if the status of the CL is equal to the order status; if they are equal, clear the monitoring counter for this CL and continue the loop.
            - for each CL Element check if the status of an Element are equal to the orderstatus
            - if all CL Element status are equal to the orderstatus, update the CL status, clear the monitoring counter for this control loop and continue the loop.
            - the message CONTROLLOOP_UPDATE/CONTROL_LOOP_STATE_CHANGE to participant will be sent if:

...