XOA Core
XOA Core is an open-source test suite framework for network automation and testing. It is designed to host various XOA RFC Test Suites as plugins, allowing users to create, manage, and run test cases for different network scenarios. The XOA Core framework serves as the foundation for building and executing test suites in the XOA ecosystem.
+------------+
| | +-------------+
| | - | plugin2544 |
| | +-------------+
| | +-------------+
| XOA Core | - | plugin2889 |
| | +-------------+
| | +-------------+
| | - | plugin3918 |
| | +-------------+
+------------+
Key features of XOA Core include:
-
Modular architecture: The test suite framework employs a modular architecture, enabling users to develop and run different test suites as plugins.
-
Test Suite execution: XOA Core supports both local and remote test suite execution. Users can execute test suites on their local machines or on remote testbeds through the XOA CLI or Web GUI.
-
Test Case management: XOA Core provides tools for managing test cases, including creating, updating, and deleting them. Users can also organize test cases using tags and execute them in parallel or sequentially.
-
Extensibility: The framework is designed to be extensible, allowing users to develop custom test suites and plugins to address specific testing requirements.
-
Logging and reporting: XOA Core offers built-in logging and reporting functionality, generating detailed test reports to help users analyze test results and identify issues.
XOA Core is the framework that provides a standardized way for developers and test specialists to execute, develop, and integrate test suites, as well as managing Xena's physical and virtual Traffic Generation and Analysis (TGA) testers.
Documentation
The user documentation is hosted: XOA Core Documentation
Step-by-Step
This section provides a step-by-step guide on how to use XOA Core to run XOA test suites.
Create Project Folder
To run XOA test suites, you need a folder to place the test suite plugins, the test configuration files, and yous Python script to control the tests.
Let's create a folder called /my_xoa_project
/my_xoa_project
|
Install XOA Core and XOA Converter
After creating the folder, install tdl-xoa-core and tdl-xoa-converterusing pip:
pip install tdl-xoa-core -U
pip install tdl-xoa-converter -U
Place Test Suite Plugins
Place the corresponding XOA RFC test suite plugins and the test configuration files in /my_xoa_project.
Your project folder will look like this afterwards.
/my_xoa_project
|
|- /test_suites
|- /plugin2544
|- /plugin2889
|- /plugin3918
Run Tests from Xena RFC Test Suite Configurations
Read more about XOA Config Convert
Copy your Xena test configurations into /my_xoa_project for easy access. Then create a main.py file inside the folder /my_xoa_project.
/my_xoa_project
|
|- main.py
|- old_2544_config.v2544
|- old_2889_config.v2889
|- old_3918_config.v3918
|- /test_suites
|- /plugin2544
|- /plugin2889
|- /plugin3918
This main.py controls the test workflow, i.e. load the configuration files, start tests, receive test results, and stop tests. The example below demonstrates a basic flow for you to run XOA tests.
from __future__ import annotations
import sys
from xoa_core import (
controller,
types,
)
import asyncio
import json
from pathlib import Path
# XOA Converter is an independent module and it needs to be installed via `pip install tdl-xoa-converter`
try:
from xoa_converter.entry import converter
from xoa_converter.types import TestSuiteType
except ImportError:
print("XOA Converter is an independent module and it needs to be installed via `pip install tdl-xoa-converter`")
sys.exit()
PROJECT_PATH = Path(__file__).parent
OLD_2544_CONFIG = PROJECT_PATH / "old_2544_config.v2544"
OLD_2889_CONFIG = PROJECT_PATH / "old_2889_config.v2889"
PLUGINS_PATH = PROJECT_PATH / "test_suites"
async def subscribe(ctrl: "controller.MainController", channel_name: str, fltr: set["types.EMsgType"] | None = None) -> None:
async for msg in ctrl.listen_changes(channel_name, _filter=fltr):
print(msg)
async def main() -> None:
# Define your tester login credentials
my_tester_credential = types.Credentials(
product=types.EProductType.VALKYRIE,
host="10.20.30.40"
)
# Create a default instance of the controller class.
ctrl = await controller.MainController()
# Register the plugins folder.
ctrl.register_lib(str(PLUGINS_PATH))
# Add tester credentials into teh controller. If already added, it will be ignored.
# If you want to add a list of testers, you need to iterate through the list.
await ctrl.add_tester(my_tester_credential)
# Subscribe to test resource notifications.
asyncio.create_task(subscribe(ctrl, channel_name=types.PIPE_RESOURCES))
# Convert Xena 2544 config into XOA 2544 config and run.
with open(OLD_2544_CONFIG, "r") as f:
# get rfc2544 test suite information from the core's registration
info = ctrl.get_test_suite_info("RFC-2544")
if not info:
print("Test suite is not recognized.")
return None
# convert the old config file into new config file
new_data = converter(TestSuiteType.RFC2544, f.read())
# you can use the config file below to start the test
new_config = json.loads(new_data)
# Test suite name: "RFC-2544" is received from call of c.get_available_test_suites()
execution_id = ctrl.start_test_suite("RFC-2544", new_config)
# The example here only shows a print of test result data.
asyncio.create_task(
subscribe(ctrl, channel_name=execution_id, fltr={types.EMsgType.STATISTICS})
)
# By the next line, we prevent the script from being immediately
# terminated as the test execution and subscription are non blockable, and they ran asynchronously,
await asyncio.Event().wait()
if __name__ == "__main__":
asyncio.run(main())
Receive Test Result Data
XOA Core sends test result data (in JSON format) to your code as shown in the example below. It is up to you to decide how to process it, either parse it and display in your console, or store them into a file.
Read about Test Result Types
Metadata
Release files for tdl-xoa-core 1.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| tdl_xoa_core-1.2.0.tar.gz | 26.4 kB | Without provenance | Details for tdl_xoa_core-1.2.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| tdl_xoa_core-1.2.0-py3-none-any.whl | Python 3 | none | any | Details for tdl_xoa_core-1.2.0-py3-none-any.whl |
Total release size: 65.4 kB
Release files / tdl_xoa_core-1.2.0.tar.gz
| Download URL | tdl_xoa_core-1.2.0.tar.gz |
|---|---|
| Size | 26.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
8affcd16d81d83aa56fa6c1b9af2ca0c028907b04541f0000615d1effbaf1ae5
|
|
BLAKE2b-256 checksum How to use checksums |
69a5dc86d94f7c01c30d46f3b32dbb7cfe2ca8d6fee57d358f1dd393e6aa9efd
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.9.25
|
Release files / tdl_xoa_core-1.2.0-py3-none-any.whl
| Download URL | tdl_xoa_core-1.2.0-py3-none-any.whl |
|---|---|
| Size | 38.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
b88d0a53776f57c2534161c74255fcd75082f1f071b1b12066a91b46b985baf3
|
|
BLAKE2b-256 checksum How to use checksums |
2ab8d0877dcaedfaf4de10dea20c6d674727285ef4b2f840608e81e7d61996c4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.9.25
|
Security for tdl-xoa-core 1.2.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.