docs/development/devtools/smoke/clamp-ac-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 use cases 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 several 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-ac-pf-ppnt, policy-clamp-ac-http-ppnt, policy-clamp-ac-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 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 policy-clamp-runtime-acm 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_PRIME 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 an automation composition definition 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_PRIME 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_PRIME_ACK going from runtime to participant
  93
  94 3.4 Participant DePriming
  95 =========================
  96
  97 When an 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_PRIME 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_PRIME_ACK going from runtime to participant
 107
 108 3.5 Automation Composition Instance
 109 ===================================
 110
 111 Automation Composition Instance handles creation, change, and deletion of automation composition instances on participants.
 112 Action: Trigger acm instantiation from GUI
 113
 114 Test result:
 115
 116 - Observe that the acm instances and respective property values for participant are stored on AutomationCompositionHandler
 117 - Observe that the acm deploy state is UNDEPLOYED
 118
 119 3.6 Automation Composition deploy state change to DEPLOYED
 120 ==========================================================
 121
 122 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
 123 Action: Change deploy state of the acm to DEPLOYED
 124
 125 Test result:
 126
 127 - Observe AUTOMATION_COMPOSITION_DEPLOY going from runtime to participant
 128 - Observe that the AutomationCompositionElements deploy state is DEPLOYED
 129 - Observe that the acm deploy state is DEPLOYED
 130 - Observe AUTOMATION_COMPOSITION_DEPLOY_ACK going from participant to runtime
 131
 132 3.7 Automation Composition lock state change to UNLOCK
 133 ======================================================
 134
 135 Action: Change lock state of the acm to UNLOCK
 136
 137 Test result:
 138
 139 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
 140 - Observe that the AutomationCompositionElements lock state is UNLOCK
 141 - Observe that the acm state is UNLOCK
 142 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 143
 144 3.8 Automation Composition lock state change to LOCK
 145 ====================================================
 146
 147 Action: Change lock state of the acm to LOCK
 148
 149 Test result:
 150
 151 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
 152 - Observe that the AutomationCompositionElements lock state is LOCK
 153 - Observe that the acm lock state is LOCK
 154 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 155
 156 3.9 Automation Composition deploy state change to UNDEPLOYED
 157 ============================================================
 158
 159 Action: Change deploy state of the acm to UNDEPLOYED
 160
 161 Test result:
 162
 163 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
 164 - Observe that the AutomationCompositionElements deploy state is UNDEPLOYED
 165 - Observe that the acm deploy state is UNDEPLOYED
 166 - Observe that the AutomationCompositionElements undeploy the instances from respective frameworks
 167 - Observe that the automation composition instances are removed from participants
 168 - Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 169
 170 3.10 Automation Composition monitoring and reporting
 171 ====================================================
 172
 173 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
 174 Action: Bring up participant
 175
 176 Test result:
 177
 178 - Observe that PARTICIPANT_STATUS message is sent from participants to runtime in a regular interval
 179 - Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of automation composition type definitions sent
 180   from all the participants to runtime
 181
 182 This concluded the required smoke tests
 183