WRCP Tester Plugin
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
├── 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
- 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" -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
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'