☰
Conductor Documentation

WRCP Tester Plugin

Overview

The purpose of this plugin, and the blueprint.yaml file, is to provide a simple field modifiable testing framework.

Theory of operation

The intent of the plugin is to allow a field team to 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 (run on Studio Conductor) the test folder must included a “main.local” file and shouldn’t contain the “main” file. These scripts (or executables) rely on the #!(shebang) 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

❯ tree blueprint
blueprint
├── blueprint.yaml
└── tests
    ├── test-1
    │   └── main
    └── test-2
        └── main

3 directories, 3 files

❯ zip -r blueprint.zip blueprint

❯ zipinfo -1 blueprint.zip
blueprint/
blueprint/blueprint.yaml
blueprint/tests/
blueprint/tests/test-1/
blueprint/tests/test-1/main
blueprint/tests/test-2/
blueprint/tests/test-2/main

tosca_definitions_version: cloudify_dsl_1_4

imports:
  - cloudify/types/types.yaml
  - plugin:wrcp-tester-plugin?version=>=24.9,<25

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.

Properties

Running using CLI

Running using UI

The dashboard is the easiest way to run and check the tests results.

  1. Go to Precheck Dashboard
  2. Click the “Execute tests” button
  3. 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
  4. Start the test and wait it finishes
    • The results will be present on the “Precheck Dashboard” widget

Precheck Dashboard

Deployment list

Test Results List

Precheck Dashboard

Filter

Include or exclude desired tests appending to a list, or 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*$"] } }' -g tester_group

Timeout

The timeout value defined in the execution defines how much time a test can run before raising an error

#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, 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

#!/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

#!/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()


#!/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

#!/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'