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