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