docs/development/devtools/clamp-cl-participant-protocol-smoke.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. _clamp-participant-protocol-smoke-tests:
   3
   4 CLAMP Participant Protocol Smoke Tests
   5 --------------------------------------
   6
   7 1. Introduction
   8 ***************
   9
  10 The CLAMP Control Loop Participant protocol is an asynchronous protocol that is used by the CLAMP runtime
  11 to coordinate life cycle management of Control Loop instances.
  12 This document will serve as a guide to do smoke tests on the different usecases that are involved when
  13 working with the Participant protocol and outline how they operate.
  14 It will also show a developer how to set up their environment for carrying out smoke tests on the participants.
  15
  16 2. Setup Guide
  17 **************
  18
  19 This section will show the developer how to set up their environment to start testing participants with some
  20 instructions on how to carry out the tests. There are a number of prerequisites. Note that this guide is written by a
  21 Linux user - although the majority of the steps show will be exactly the same in Windows or other systems.
  22
  23 2.1 Prerequisites
  24 =================
  25
  26 - Java 11
  27 - Docker
  28 - Maven 3
  29 - Git
  30 - Refer to this guide for basic environment setup `Setting up dev environment <https://wiki.onap.org/display/DW/Setting+Up+Your+Development+Environment>`_
  31
  32 2.2 Setting up the components
  33 =============================
  34
  35 - Controlloop runtime component docker image is started and running.
  36 - Participant docker images policy-clamp-cl-pf-ppnt, policy-clamp-cl-http-ppnt, policy-clamp-cl-k8s-ppnt are started and running.
  37 - Dmaap simulator for communication between components.
  38 - mariadb docker container for policy and controlloop database.
  39 - policy-api for communication between policy participant and policy-framework
  40
  41 In this setup guide, we will be setting up all the components technically required for a working convenient
  42 dev environment. We will not be setting up all of the participants - we will setup only the policy participant as an
  43 example.
  44
  45 2.2.1 MariaDB Setup
  46 ===================
  47
  48 We will be using Docker to run our mariadb instance. It will have a total of two databases running in it.
  49
  50 - controlloop: the runtime-controlloop db
  51 - policyadmin: the policy-api db
  52
  53 3. Running Tests of protocol dialogues
  54 **************************************
  55
  56 loop type definitions and common property values for participant types.
  57
  58 In this section, we will run through the functionalities mentioned at the start of this document is section 1. Each functionality will be tested and we will confirm that they were carried out successfully. There is a tosca service template that can be used for this test
  59 :download:`Tosca Service Template <tosca/tosca-for-gui-smoke-tests.yaml>`
  60
  61 3.1 Participant Registration
  62 ============================
  63
  64 Action: Bring up the participant
  65
  66 Test result:
  67
  68 - Observe PARTICIPANT_REGISTER going from participant to runtime
  69 - Observe PARTICIPANT_REGISTER_ACK going from runtime to participant
  70 - Observe PARTICIPANT_UPDATE going from runtime to participant
  71
  72 3.2 Participant Deregistration
  73 ==============================
  74
  75 Action: Bring down the participant
  76 Test result:
  77
  78 - Observe PARTICIPANT_DEREGISTER going from participant to runtime
  79 - Observe PARTICIPANT_DEREGISTER_ACK going from runtime to participant
  80
  81 3.3 Participant Priming
  82 =======================
  83
  84 When a control loop is primed, the portion of the Control Loop Type Definition and Common Property values for the participants
  85 of each participant type mentioned in the Control Loop Definition are sent to the participants.
  86 Action: Invoke a REST API to prime controlloop type definitions and set values of common properties
  87
  88 Test result:
  89
  90 - Observe PARTICIPANT_UPDATE going from runtime to participant with controlloop type definitions and common property values for participant types
  91 - Observe that the controlloop type definitions and common property values for participant types are stored on ParticipantHandler
  92 - Observe PARTICIPANT_UPDATE_ACK going from runtime to participant
  93
  94 3.4 Participant DePriming
  95 =========================
  96
  97 When a control loop is de-primed, the portion of the Control Loop Type Definition and Common Property values for the participants
  98 of each participant type mentioned in the Control Loop Definition are deleted on participants.
  99 Action: Invoke a REST API to deprime controlloop type definitions
 100
 101 Test result:
 102
 103 - If controlloop instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission controlloop type definition"
 104 - If no controlloop instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null
 105 - Observe that the controlloop type definitions and common property values for participant types are removed on ParticipantHandler
 106 - Observe PARTICIPANT_UPDATE_ACK going from runtime to participant
 107
 108 3.5 Control Loop Update
 109 =======================
 110
 111 Control Loop Update handles creation, change, and deletion of control loops on participants.
 112 Action: Trigger controlloop instantiation from GUI
 113
 114 Test result:
 115
 116 - Observe CONTROL_LOOP_UPDATE going from runtime to participant
 117 - Observe that the controlloop type instances and respective property values for participant types are stored on ControlLoopHandler
 118 - Observe that the controlloop state is UNINITIALISED
 119 - Observe CONTROL_LOOP_UPDATE_ACK going from participant to runtime
 120
 121 3.6 Control Loop state change to PASSIVE
 122 ========================================
 123
 124 Control Loop Update handles creation, change, and deletion of control loops on participants.
 125 Action: Change state of the controlloop to PASSIVE
 126
 127 Test result:
 128
 129 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 130 - Observe that the ControlLoopElements state is PASSIVE
 131 - Observe that the controlloop state is PASSIVE
 132 - Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
 133
 134 3.7 Control Loop state change to RUNNING
 135 ========================================
 136
 137 Control Loop Update handles creation, change, and deletion of control loops on participants.
 138 Action: Change state of the controlloop to RUNNING
 139
 140 Test result:
 141
 142 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 143 - Observe that the ControlLoopElements state is RUNNING
 144 - Observe that the controlloop state is RUNNING
 145 - Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
 146
 147 3.8 Control Loop state change to PASSIVE
 148 ========================================
 149
 150 Control Loop Update handles creation, change, and deletion of control loops on participants.
 151 Action: Change state of the controlloop to PASSIVE
 152
 153 Test result:
 154
 155 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 156 - Observe that the ControlLoopElements state is PASSIVE
 157 - Observe that the controlloop state is PASSIVE
 158 - Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
 159
 160 3.9 Control Loop state change to UNINITIALISED
 161 ==============================================
 162
 163 Control Loop Update handles creation, change, and deletion of control loops on participants.
 164 Action: Change state of the controlloop to UNINITIALISED
 165
 166 Test result:
 167
 168 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 169 - Observe that the ControlLoopElements state is UNINITIALISED
 170 - Observe that the controlloop state is UNINITIALISED
 171 - Observe that the ControlLoopElements undeploy the instances from respective frameworks
 172 - Observe that the control loop instances are removed from participants
 173 - Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
 174
 175 3.10 Control Loop monitoring and reporting
 176 ==========================================
 177
 178 This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Control Loop Elements, and to gather statistics on control loops. The ParticipantStatus message is sent periodically by each participant. The reporting interval for sending the message is configurable
 179 Action: Bring up participant
 180
 181 Test result:
 182
 183 - Observe that PARTICIPANT_STATUS message is sent from participants to runtime in a regular interval
 184 - Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of control loop type definitions sent
 185   from all the participants to runtime
 186
 187 This concluded the required smoke tests
 188