1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. _clamp-participant-protocol-smoke-tests:
4 CLAMP Participant Protocol Smoke Tests
5 --------------------------------------
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.
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.
30 - Refer to this guide for basic environment setup `Setting up dev environment <https://wiki.onap.org/display/DW/Setting+Up+Your+Development+Environment>`_
32 2.2 Setting up the components
33 =============================
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
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
48 We will be using Docker to run our mariadb instance. It will have a total of two databases running in it.
50 - clampacm: the runtime-clampacm db
51 - policyadmin: the policy-api db
53 3. Running Tests of protocol dialogues
54 **************************************
56 loop type definitions and common property values for participant types.
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>`
61 3.1 Participant Registration
62 ============================
64 Action: Bring up the participant
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
72 3.2 Participant Deregistration
73 ==============================
75 Action: Bring down the participant
78 - Observe PARTICIPANT_DEREGISTER going from participant to runtime
79 - Observe PARTICIPANT_DEREGISTER_ACK going from runtime to participant
81 3.3 Participant Priming
82 =======================
84 When an 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
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
94 3.4 Participant DePriming
95 =========================
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
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
108 3.5 Automation Composition Update
109 =================================
111 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
112 Action: Trigger acm instantiation from GUI
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
121 3.6 Automation Composition state change to PASSIVE
122 ==================================================
124 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
125 Action: Change state of the acm to PASSIVE
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
134 3.7 Automation Composition state change to RUNNING
135 ==================================================
137 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
138 Action: Change state of the acm to RUNNING
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
147 3.8 Automation Composition state change to PASSIVE
148 ==================================================
150 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
151 Action: Change state of the acm to PASSIVE
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
160 3.9 Automation Composition state change to UNINITIALISED
161 ========================================================
163 Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
164 Action: Change state of the acm to UNINITIALISED
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
175 3.10 Automation Composition monitoring and reporting
176 ====================================================
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
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
187 This concluded the required smoke tests