WRCP Tester Plugin

Requirements

WRCP Deployment for the Tester to use as the target
wrcp_tester wagon and plugin.yaml file

blueprint.yaml must be inside of a zip folder with the tests and gather scripts, as shown below

[centos@localhost examples]$ tree
├── blueprint.yaml
├── gather
└── tests
├── test1
│   └── main
├── test2
│   └── main.local
└── test3        
    └── main

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
1. Upload the tester plugin
2. Upload the tester blueprint
3. Create a WRCP deployment group
4. Extend filtered deployments to the WRCP group (created at step 4)
5. Create tester deployment group, using tester blueprint
6. Extend tester group into wrcp environment group
7. 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" -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 executions group start execute_operation -p '{"operation": "windriver.interfaces.test.run_tests"}' -g tester_group

Gather Script

The purpose of the Gather Script is to simplify how the result is shown in the terminal.

Run chmod +x gather to ensure the script can be executed
To use it, go to the folder where you have Gather Script and run it:

./gather tester_group_name

This command returns a list of dictionaries like this

"None":

[{

   "name":"test",
   "passed":true,
   "output":"2023-01-10 20:48:44.895252\n",
   "local":false,
   "started_time":"2023-01-08T11:52:05.107370",
   "end_time":"2023-01-08T11:52:06.016341"
}]

The “None” at first line is the “csys-location-name” label of WRCP target and show the name of target or “None” if no name is defined

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. A “Deployment Group” in a list b. The timeout setting the “Timeout” field c. The list of desired tests to be executed setting the “Tests” field with the name of each test d. 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 a. 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

Precheck Dashboard

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 Starlingx/K8S API	yes
Run bash scripts?	no	yes
Run tests with StarlingX 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 StarlingX API

There are two decorators that use Starlingx API: @with_system_configuration_management and @with_distributed_cloud_connection

@with_system_configuration_management decorator has StarlingX 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 StarlingX 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 StarlingX 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'