WRCP Tester Plugin
Overview
The purpose of this plugin, and an accompanying blueprint (as in examples), is to provide a simple field modifiable testing framework. The plugin operation assumes a WRCP Conductor environment already exists, as produced by WRCP plugin discovery.
Theory of operation
The idea behind the framework is that a field team can use a standard blueprint to develop
and run tests. The blueprint.yaml
file is not intended to be modified. Tests are added
in the tests
subdirectory of the blueprint. Each subdirectory of tests
represents a test,
and includes a script named main
. For local test (ran on conductor) the test folder must included a “main.local” file and shouldn’t
contain the “main” file. These scripts (or executables) rely on the #!
first
line to determine the interpreter. The script directory can contain any artifacts necessary
for the tests. At test time, the tests directories are copied to remote hosts and executed.
Results are return on stdout
(or stderr
for errors) and standard unix semantics determine pass/fail: passed tests exit with 0.
To run commands with sudo in the tests without being
prompted for a password, it’s necessary to use it with the following structure (the value
attributed for SUDO_PWD
is imported from the blueprint.yaml
file):
echo $SUDO_PWD | sudo -S bash -c <command>
Requirements
- WRCP Deployment for the Tester to use as the target
wrcp_tester wagon
andplugin.yaml
fileblueprint.yaml
must be inside of a zip folder with the tests and gather scripts, as shown below
[centos@localhost examples]$ tree
├── blueprint.yaml
└── tests
├── test1
│ └── main
├── test2
│ └── main.local
└── test3
└── main
- Blueprint content:
tosca_definitions_version: cloudify_dsl_1_3
imports:
- https://cloudify.co/spec/cloudify/6.0.0/types.yaml
- plugin:wrcp-tester-plugin
blueprint_labels:
custom-node-type:
values:
- wrcp-tester
node_templates:
test:
type: windriver.tester.nodes.TestDriver
Node types
windriver.tester.nodes.TestDriver This node represents the driver that performs tests connecting to WRCP targets.
Properites
- ssh_creds: A dictionary containing the keys ‘user’ and ‘password’ representing the connection credentials. Assumes all test targets have same.
- tests: A list of test directories in blueprint. If omitted, all sub-directories of the ‘tests’ directory in the blueprint will be used.
Running using CLI
-
Make sure you are attempting to run the test on a system controller (deployment labeled with ‘Wind-River-Cloud-Platform-System-Controller’) or subcloud (labeled with ‘Wind-River-Cloud-Platform-Subcloud’)
-
The Tester framework uses WRCP deployments as a target
-
You must filter which WRCP deployments will be added to the group (i.e. step 4)
-
WRCP deployments can be filtered in many different ways, run “cfy deployment group extend -h” to see possible filters
- Upload the tester plugin
- Upload the tester blueprint
- Create a WRCP deployment group
- Extend filtered deployments to the WRCP group (created at step 4)
- Create tester deployment group, using tester blueprint
- Extend tester group into wrcp environment group
- Run all the tests
cfy plugins upload wrcp_tester_plugin.wgn -y plugin.yaml
cfy blueprints upload blueprint.zip -b tester-blueprint
cfy deployments group create wrcp_group
cfy deployment group extend -ar "blueprint_id=<WRCP_BLUEPRINT_NAME>" -lr "csys-env-type=Wind-River-Cloud-Platform-System-Controller" wrcp_group
cfy deployment group create -b tester-blueprint tester_group
cfy deployments group extend --into-environments wrcp_group tester_group
cfy execution group start install -g <tester_group_name>
cfy executions group start execute_operation -p '{"operation": "windriver.interfaces.test.run_tests"}' -g tester_group
Running using UI
The dashboard is the easiest way to run and check the tests results. The dashboard is the last page in Conductor left panel
- Go to Precheck Dashboard
- Click the “Execute tests” button
- A modal is displayed where the user can select:
- A “Deployment Group” in a list
- The timeout setting the “Timeout” field
- The list of desired tests to be executed setting the “Tests” field with the name of each test
- The list of tests to be exclude from execution setting the “Exclude” field with the name of each test
- Start the test and wait it finishes
- The results must be present in “Results grid”
Precheck Dashboard
Deployment list
- Deployments that are highlighted in red have at least 1 failed test
- Deployments that aren’t highlighted only have successful results
- “Deployment” column shows the WRCP target of the Tester deployments
- The green button “Success” filters the successful tester deployments and the “Fail” button the failed ones
- Check the tests clicking in the desired Tester deployment
- Click into the desired title to sort the Tester deployments
- Tester Deployments with 2 or more WRCP targets have the same “started” values (i.e. the last two deployments)
Test Results List
- Tests highlighted in red are failed tests, tests that aren’t highlighted are successful tests
- The icon in the “Result” column shows the output
- Click into the desired title to order the tests
Filter
Include or exclude desired tests appending to a list, or using regex
-
Add the tests that will run to the “tests” list
-
Add the tests that won’t run to the “exclude” list
-
Include or exclude using regex
#just remote-bash will run
cfy executions group start execute_operation -p '{"operation": "windriver.interfaces.test.run_tests", "operation_kwargs": { "tests": ["remote-bash"]}}' -g tester_group
#just local test will not run
cfy executions group start execute_operation -p '{"operation": "windriver.interfaces.test.run_tests", "operation_kwargs": { "exclude": ["local"]}}' -g tester_group
#just the ones with "remote-" at the name will run
cfy executions groups start execute_operation -p '{"operation": "windriver.interfaces.test.run_tests", "operation_kwargs": { "tests": ["^remote*$"] } }
Timeout
The timeout value defined in the execution defines how much time a test can run before raising an error
-
If the tests take longer than the timeout value, the plugin show the next error: Timeout Error: test took too long to finish (30s)
-
A default timeout of 300s is assumed, but you can change for the desired value
#in this example, 30s timeout has been set
cfy executions groups start execute_operation -p '{"operation": "windriver.interfaces.test.run_tests", "operation_kwargs": {"timeout": 30}}' -g test_group
Remote vs Local tests
Frequent questions | Local | Remote |
---|---|---|
Where the tests run? | local conductor | WRCP host |
Run python scripts? | yes, only test with WRCP/K8S API | yes |
Run bash scripts? | no | yes |
Run tests with WRCP API? | yes | no |
Run tests with Kubernetes API? | yes | no |
Need a file name extension to run ? | .local | no |
Run sudo passwordless script? | - | yes |
Tests with Kubernetes API
-
@with_k8s_client decorator must be used in python script
-
The test only run in local conductor, so use .local in your script extension
#!/usr/bin/env python
from kubernetes import client
from wrcp_tester.common.decorators import with_kubernetes_client
@with_kubernetes_client
def list_pods(k8s_client):
core_v1 = client.CoreV1Api(k8s_client)
pod_result = core_v1.list_pod_for_all_namespaces()
print("{:<18}{:<20}{}".format("pod_id", "namespace", "name"))
for pod in pod_result.items:
print("{:<18}{:<20}{}".format(
pod.status.pod_ip,
pod.metadata.namespace,
pod.metadata.name))
if __name__ == "__main__":
list_pods()
Tests with WRCP API
There are two decorators that use WRCP API: @with_system_configuration_management and @with_distributed_cloud_connection
- @with_system_configuration_management decorator has WRCP general commands
#!/usr/bin/env python
from wrcp_tester.common.decorators import with_system_configuration_management
@with_system_configuration_management
def sample_test(conn):
"""Sample test using WRCP System Configuration Management (cgts-client) API
Args:
conn: authenticated client connection
"""
print("RESPONSE", conn.ihost.list())
if __name__ == "__main__":
sample_test()
- @with_distributed_cloud_connection decorator has DC Systems commands
#!/usr/bin/env python
from wrcp_tester.common.decorators import with_distributed_cloud_connection
@with_distributed_cloud_connection
def sample_test(conn):
"""Sample test using WRCP Distributed Cloud Client (distcloud-client) API
Args:
conn: authenticated client connection
"""
alarms = conn.alarm_manager.list_alarms()
for alarm in alarms:
print("STATUS ", alarm.status)
if __name__ == "__main__":
sample_test()
Tests with Sudo
-
Sudo commands will run without prompt for password input
-
The test will import the sudo password from secrets read from the parent WRCP deployment
-
Follow the structure at line 5
#!/bin/sh |
echo "Test needs sudo: cat /etc/grub2.cfg"
#echo $SUDO_PWD | sudo -S bash -c <command>
echo $SUDO_PWD | sudo -S bash -c 'cat /etc/grub2.cfg'