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 Automation Composition Participant protocol is an asynchronous protocol that is used by the CLAMP runtime
  11 to coordinate life cycle management of Automation Composition 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 - Automation Composition 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 clampacm 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 - clampacm: the runtime-clampacm 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 automation composition is primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
  85 of each participant type mentioned in the Automation Composition Definition are sent to the participants.
  86 Action: Invoke a REST API to prime acm type definitions and set values of common properties
  87
  88 Test result:
  89
  90 - Observe PARTICIPANT_UPDATE going from runtime to participant with acm type definitions and common property values for participant types
  91 - Observe that the acm 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 automation composition is de-primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
  98 of each participant type mentioned in the Automation Composition Definition are deleted on participants.
  99 Action: Invoke a REST API to deprime acm type definitions
 100
 101 Test result:
 102
 103 - If acm instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission acm type definition"
 104 - If no acm instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null
 105 - Observe that the acm 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 Automation Composition Update
 109 =================================
 110
 111 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
 112 Action: Trigger acm instantiation from GUI
 113
 114 Test result:
 115
 116 - Observe AUTOMATION_COMPOSITION_UPDATE going from runtime to participant
 117 - Observe that the acm type instances and respective property values for participant types are stored on AutomationCompositionHandler
 118 - Observe that the acm state is UNINITIALISED
 119 - Observe AUTOMATION_COMPOSITION_UPDATE_ACK going from participant to runtime
 120
 121 3.6 Automation Composition state change to PASSIVE
 122 ==================================================
 123
 124 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
 125 Action: Change state of the acm to PASSIVE
 126
 127 Test result:
 128
 129 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
 130 - Observe that the AutomationCompositionElements state is PASSIVE
 131 - Observe that the acm state is PASSIVE
 132 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 133
 134 3.7 Automation Composition state change to RUNNING
 135 ==================================================
 136
 137 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
 138 Action: Change state of the acm to RUNNING
 139
 140 Test result:
 141
 142 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
 143 - Observe that the AutomationCompositionElements state is RUNNING
 144 - Observe that the acm state is RUNNING
 145 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 146
 147 3.8 Automation Composition state change to PASSIVE
 148 ==================================================
 149
 150 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
 151 Action: Change state of the acm to PASSIVE
 152
 153 Test result:
 154
 155 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
 156 - Observe that the AutomationCompositionElements state is PASSIVE
 157 - Observe that the acm state is PASSIVE
 158 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 159
 160 3.9 Automation Composition state change to UNINITIALISED
 161 ========================================================
 162
 163 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
 164 Action: Change state of the acm to UNINITIALISED
 165
 166 Test result:
 167
 168 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
 169 - Observe that the AutomationCompositionElements state is UNINITIALISED
 170 - Observe that the acm state is UNINITIALISED
 171 - Observe that the AutomationCompositionElements undeploy the instances from respective frameworks
 172 - Observe that the automation composition instances are removed from participants
 173 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 174
 175 3.10 Automation Composition monitoring and reporting
 176 ====================================================
 177
 178 This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Automation Composition Elements, and to gather statistics on automation compositions. 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 automation composition type definitions sent
 185   from all the participants to runtime
 186
 187 This concluded the required smoke tests
 188