XPRESSO

Glossary

This glossary provides an alphabetical list of terms and acronym expansions that are unique (newly introduced, exclusive, or specialized), that are used in XPRESSO User Guide or appear on the XPRESSO dashboard. This glossary also identifies alternate term names and acronyms used in other Cisco networking user documentation.

Also refer to the following web resources for terms and acronyms not defined in this glossary.

A-D terms

Access Control: The process of granting or denying specific requests to obtain and use information and related information processing services; and enter specific physical facilities.

Actionable Request: In XPRESSO, any action that requires human intervention or approval by a Group or System Administrators generates an "Actionable request" to a corresponding party who is responsible to approve or deny this request; if approved, they are responsible for completing the appropriate action (task).

ASA: See Cisco ASA.

Baseline Job Request: You can optionally configure (set) a Job as a Baseline Job Request; you can then compare the test results from one or more other Job Requests against the Baseline Job Request. Baseline Job Requests also have the same attributes as standard as a "Job Request".

Branch: In XPRESSO, a Branch is a parallel instance of an OS revision. Branches form part of a build/release management technique; the goal of this methodology is to ensure significant builds can be validated to ensure image stability by executing a given set of Job Runs on your testbed (with or without a clean file) against the image. You can associate/apply Branch metadata with your Job Runs to assist with tracking purposes and to make working with test results easier.

Btrace: The Btrace Trace-on-Failure infrastructure provides a mechanism to achieve a summary list of Application Contexts (MAC-address, IP, string) that have had an Error (ERR) or more severe failures and a detailed list of the btrace logs that precede the failure condition. XPRESSO provides a pre-configured Webhook for Btrace if it's enabled in the group level. Detailed link

Bundle: See Job Bundle.

CDETS: Cisco Defect and Enhancement Tracking System

Cerebro: Cerebro is an open source (MIT License) elasticsearch web admin tool built using Scala, Play Framework, AngularJS and Bootstrap.

CI/CD: Continuous Integration/Continuous Delivery. The premise behind CI is to merge code from individual developers into a project multiple times per day and test continuously to avoid downstream problems. CD takes this a step further to ensure that all merged code is always in a production-ready state.

Cisco ASA: Cisco Adaptive Security Appliances. A Cisco firewall/VPN solution based on Linux for small to medium businesses.

Cisco TRADe: Cisco Test Results Analysis and Debugging (the "e" does not have an acronym definition). Cisco TRADe provides a (legacy) series of debugging tools integrated with an online log viewer (with access to log archives) that gives you the ability to view, analyze, compare, and debug pyATS runs. You can view pyATS test results posted to the Cisco TRADE Results Viewer via a quick link on the XPRESSO Results page rather than the XPRESSO dashboard.

Clean: Clean (or Device cleaning) is the process of preparing physical testbed devices to a testable steady state by: (1) loading the devices with an appropriate image (therefore recovering from a bad image) (2) removing unnecessary configurations and returning the devices to their default state (3) configuring the bare-minimum required for console/management connections. The term "Netclean" is also used on the XPRESSO dashboard; this is basically the same process of Clean but Netclean only applies to LaaS-NG configured topologies in XPRESSO.

Configuration State: Configuration states in XPRESSO reports the current configuration status of supported objects that can be configured by users. Three configuration states are supported: Enabled (default configuration state), Disabled, and Maintenance. Group Admins (or permitted users) can change the configuration state of XPRESSO Jobs, Resources, and Test Environment to meet their specific testing requirements. Differs from XPRESSO's Operational states.

CMW: Common Maintenance Window

CRUD

Create, read, update and delete. CRUD as it applies to the XPRESSO user interface; allows Users to:

create or add new entries;
read, retrieve, search, or view existing entries;
update or edit existing entries;
delete, deactivate, or remove existing entries.

CTC: CTC (commonly referred to as Testwell CTC++ is an instrumentation-based code coverage and dynamic analysis tool for C/C++ code that is commonly used to evaluate/test the comprehensiveness of test automation plans. CTC++ provides: Line, Statement, Function, Decision, Multi-condition, Modified Condition/Decision, and Condition Coverage. As a dynamic analysis tool, CTC++ shows the execution counters (how many times executed) in the code, i.e., more than a plain executed/not executed information. You can also use CTC++ to measure function execution costs (normally time) and to enable function entry/exit tracing at test time. XPRESSO provides a pre-configured Webhook for CTC that automatically adds pyATS CTC arguments so you can post information directly into Cerebro.

CRFT: CRimson Function Tracking provides ALWAYS ON function level code instrumentation. A counter is kept for each function entry. At any point in time a user can issue a CLI to dump out all the counters on the box. This data can be extremely useful to debug issues. XPRESSO provides a pre-configured Webhook for CRFT if it's enabled in the group level. Detailed link

Docker Image: Docker is part of a set of platform as a service (PaaS) products that uses OS-level virtualization to deliver software applications securely within a container, packaged with all required dependencies and libraries. A Docker image is a file, comprised of multiple layers that is used to run code and applications inside a Docker container — it's essentially halfway between an executable binary and a virtual machine and contains a filesystem, shell, executables, and other requirements. A Docker image is built from the instructions for a complete and executable version of an application. You can use a Docker Image to add (register) existing Docker Images or build new Docker images to provide a virtual equivalent of a test execution environment to execute Job Runs in the Cloud. This eliminates the need for a physical (Jenkins) execution engine or test harness; the Cloud-equivalent test execution environment provides a portable, stable, and reproducible (controlled) testing environment.

DMZ: Demilitarized Zone. A DMZ, also sometimes known as a perimeter network or a screened subnetwork, is a physical or logical subnet that separates an internal local area network (LAN) from other untrusted networks.

DUT: Device Under Test

Dynamic Testbed: See Testbed.

eARMS: extended Automated Regression Management System. The Cisco eARMS is an internal Cisco web application used to setup, schedule, and manage testbeds for running test scripts.

Easypy: Easypy is a sub-component of pyATS that aggregates script runs into encapsulated environments, collects logs into archives, and sends reporting emails.

Ecosystem: A complex network or interconnected system with the following traits and properties: distributed, adaptive, open socio-technical (both technical and social) system, self-organization, scalability and sustainability. XPRESSO forms part of the pyATS ecosystem.

F-J terms

Floating Action Button: Floating action buttons appear on the XPRESSO dashboard "dynamically" based on the type of form or wizard you are configuring. Hover over the button to reveal the tooltip which indicates which action(s) can be performed or which sub-menus can be accessed. Once a configuration form/wizard is saved, other floating action buttons may appear dynamically allowing you to perform further actions or provide information about what is configured.

Harness or Harness Instance: See Test harness.

Icon Button: An icon button is an "always-visible" graphic representation (picture) on the XPRESSO dashboard with no (visible) accompanying text. When clicked, the icon button triggers an action such as providing access to a sub-menu, launches a configuration form or wizard, or displays information you can select.

Jenkins (or Jenkins Automation Server): Jenkins (also referred to as the Jenkins execution engine), is a self-contained, open source automation server used to automate the various tasks related to the building, testing, delivery, and deployment of software; the default execution engine in XPRESSO is Jenkins.

Jenkins Plugins: Jenkin plugins are the primary means of enhancing the functionality of Jenkins to suit an organization or user-specific automation needs. The following specific Jenkins plugins are used with XPRESSO and pyATS: pyATS Project Plugin; pyATS Report Plugin; and XPRESSO Plugin.

Job (or Job Run): Each pyATS script run is prepped and launched via its corresponding Job in XPRESSO. A "Job" or "Job Run" is the aggregation of one or more pyATS test scripts that share the same attributes that are executed together within the same runtime environment. Shared attributes include (for example), the Job Name, defining which pyATS script to execute, which Execution Engine and Test harness to use, any Job/Environment/pyATS arguments that need to be applied, and which testbeds or topologies to use.
A Job added to XPRESSO follows the same design concepts as an Easypy Jobfile. When you add a Job, they are associated with a least one Job Profile (the DEFAULT Job profile) but can have many which means the Job can be run in a different environment or against a different set of testbeds. Once you create a Job, they are registered in XPRESSO and saved with a unique name for identification and tracking purposes.

Job Bundle: Job Bundles (also truncated to just "Bundle" on the XPRESSO Dashboard) are grouped combinations of "saved" Jobs (multiple jobs can be selected) and Job Profiles so they can be re-run at a later date. Job Bundles lets you group any combination of Jobs together as a "single" entity (along with as many Job Profiles as required) but lets you schedule them as a "discrete or single" object. Job Bundles are in essence, a "batch" processing tool that has the same attributes of a "testing-template". Not to be confused with a "Job Group".

Job Group: A Job Group is simply selecting a list of Jobs on-the-fly for execution rather then selecting one job at a time. You cannot save a Job Group. Not to be confused with a Job Bundle.

Job Profile: In XPRESSO, a "Job Profile" contains the metadata information associated with a Job that defines how to run your Job such as which arguments, test harness, Execution Engine, testbeds, or LaaS-NG topologies that apply to a particular test run. It allows you to create multiple variation of the Job based on settings defined in the metadata. At a minimum, a Job is always associated with a DEFAULT Job profile when you add a new Job to XPRESSO. You can create or clone additional Job profiles and associate them to your Job so you can run your Job in different testing environments. When you create a Job Profile, they are registered in XPRESSO and saved with a unique name for identification and tracking purposes. Job Profiles are located under each registered Job on the Job details page.
Each Job in XPRESSO, can have one or more associate Job Profiles. A Job and a Job Profile together define an executable suite to run.

Job Request (also refer to as a Run Request): When you save a Job in XPRESSO and the Job is submitted for execution and queued (therefore, the job is set to “Run” on the Registered Jobs page); the Job is now considered to be a "Job Request" (also known a Run Request and is truncated to just "Request" on the XPRESSO Dashboard); you do not directly create Job Requests.You can however, configure additional parameter settings with the Job Request to further define the test environment your Job will execute in. For example, you can select/de-select which testbeds to use, specify your clean file requirements and Job/Environment/Harness arguments, and configure optional parameters such as establishing a baseline test run or running your tests on multiple testbeds.
Job Requests can be run individually, in Job Groups, or in Job Bundles. When XPRESSO creates a Job Request, they are registered in XPRESSO and saved with unique ID for identification and tracking purposes.
The Job Request executes when the testbed resources become available or when the Job is scheduled to run. Once the Job Request completes the run, it contains your test results. You can optionally view job execution statistics in real-time using LiveView when a Job Request is running.

Job Test Results

Once a Job Request completes a Job Run in XPRESSO, it contains your Job test results and (if set), the comparison data against a baseline. Also see "Baseline Job Request". You can then:

Search your Job test results.
View a quick-look Results Summary that provides a Pass/Fail breakdown for all test cases in your Job Request.
View Job test result details that displays a line-by-line log of all test cases in your Job Request broken down to each section, sub-section, and each discrete executed device command.
View your Job test results in Cisco TRADe.

JWT: JSON Web Token. JWT is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. XPRESSO REST APIs require the use of an API Token to authenticate users using JWT.

K-0 terms

LaaS: Lab as a Service. Not to be confused with: "Infrastructure of a service", "Linux as a Service" or "Location as a Service".

LaaS Instance: System Admin can add (register) a LaaS Instance in XPRESSO at a Group level to request access to hardware resources through a defined server to eliminate the requirement to create a physical testbeds for each test, to enhance lab resource usage, and as a staging area for scenario deployment prior to running. Once the LaaS Instance is registered in XPRESSO, Group members can run their Jobs on the LaaS instance.

LaaS-NG: LaaS-Next Generation. LaaS-NG (also truncated to LaaSNG) is a network orchestration tool (testbed) used to create on-the-fly network topologies with both physical and virtual hardware to represent or describe Cisco platforms. LaaS-NG brings up the nodes in the topology, creates network connections among nodes and establishes console access to each node. LasS-NG is also referred to as a dynamic or logical testbed. Also see testbed.

Menu: Menus on the XPRESSO dashboard have a visible title within the menu bar, a tab on configuration form, or can be accessed from an icon button. When clicked, the menu triggers an action such as launching a configuration form or wizard. The terms sub-menu or pull-down menu may also be used if the menu is accessed from a higher level menu or icon button.

Netclean: Netclean (also referenced as vmcloud netclean or LaaSNG Clean in the Cisco LaaS user documentation). Netclean cleans (purges or resets) all devices or selected devices in a network topology of any previous user-configured settings to an established baseline and reloads the device(s) using an existing (known) clean topology using a script or image. Netclean only applies to LaaS-NG configured topologies in XPRESSO. Also see "Clean".

Notification: All auto-generated system messages in XPRESSO are called Notifications. They provide a quick at-a-glance view of an event update.

Webex Bot Notification: Important Xpresso events can be captured via Webex Teams. They post the info as Xpresso BotWebex Bot Notifications. They provide a quick at-a-glance view of an event update.

Network Orchestration: Network Orchestration, also known as Software-defined networking (SDN). Orchestration is the process of automatically programming the behavior of the network, so the network smoothly coordinates with the hardware and the software elements to further support applications and services.

Operational State: Operational states in XPRESSO reports the readiness/availability of test equipment, the transitional states as a Job Run executes, what happens when the Job Run completes, and if a problem occurs, the reason why. Operational states are view only and are set automatically by XPRESSO; you cannot configure an operational state. Differs from XPRESSO's Configuration states.

OVA: Open Virtualization Appliance. An OVA file contains a compressed, "installable" version of a virtual machine. When you open an OVA file, it extracts the VM and imports it into whichever virtualization software you have installed on your computer (in XPRESSO, with LaaS).

P-S terms

Pip (or pip): Pip installs Package. pip is the default package-management system used to install and manage additional libraries and dependencies that are not distributed as part of the Python standard library. pip is installed by default when you install Python.

Profile: XPRESSO "Profiles" provides an additional layer on top of the Job layer that lets you perform varying degree of tests (and coverages) using the same test script but with different parameters or arguments.

pyATS

Python Automated Testing Solution; also referred to as the pyATS ecosystem. The Cisco pyATS is a Python3-based test automation infrastructure comprised of the following three components:

pyATS (core)
pyATS library (also called GENIE in development)
XPRESSO dashboard (to be rebranded as the pyATS dashboard at a future date)

Registered (Object): The term Registered (Object), as in Registered Jobs, Registered Testbeds, or Registered Harness Instance, denotes that the object has been defined, configured, and saved (therefore added) to the XPRESSO database awaiting further processing such as scheduling or execution.

Run Request: See Job Request

S3 or SSS: Self-serve service. A former name of XPRESSO used internally by Cisco during development of the application. The XPRESSO dashboard is being rebranded to the pyATS dashboard at a future date.

Service Orchestration: Service orchestration is the execution of the operational and functional processes involved in designing, creating, and delivering an end-to-end service.

SDK: Software Development Kit

SSR Tool: Self-Serve Regression Tool. The SSR tool (also referred to as the SSR framework and SSL infrastructure), is an internal Cisco-only legacy test automation system that XPRESSO is replacing.

T-Z terms

TaaS: Test-as-a-Service (or Test-Automation-as-a-Service). TaaS is an use-case model for network testing/certification/validation automation where end-users can request and run tests and validation of their specification, on a testbed/topology of their choice, using commonly available hardware in the Cloud.

TRADe: See Cisco TRADe.

Tcl-ATS: Tool Command Language, but is conventionally spelled "Tcl" (pronounced "tickle") - Automated Testing Solution. Used to indicates if Tcl programming language is supported within a specific function supported by XPRESSO within the ATS. Also referenced on the XPRESSO dashboard as a TCL Config file.

Testbed: In XPRESSO, testbeds defines or represent the network devices that work together as a test platform that your tests will be executed against. XPRESSO supports the following two testbed types: Static testbeds and LaaS-NG testbeds.

Test Harness: In XPRESSO, a test harness (also referred to as a Harness or Harness Instance on the XPRESSO dashboard) defines the automated test framework properties (name, type, path, location, supported features) for the Python script execution environment associated with your pyATS instance or Tcl-ATS tree. The test harness is used in conjunction with the test execution engine and the test script repository to allow Job Runs to be executed and orchestrated within XPRESSO, resulting in the means to analyze test results.

VTY: Virtual teletype. VTY is a command line interface (CLI) created on a router and used to facilitate a connection to a daemon via Telnet. To connect to a router via VTY, users must enter a valid password.

Webhook: A Webhook (also called a web callback or HTTP push APIs) allow third-party applications to interface with XPRESSO using custom callbacks so it can deliver (push) real-time information to those apps as it updates. This differs from a typical APIs where you need to poll for data frequently to get real-time information. Some Webhooks allow third-party applications to reply to XPRESSO, and can modify its behavior in some way. All Webhooks extended through XPRESSO are maintained by their third-parties.

Wizard: A wizard is a step-by-step process that allows users to input information in a prescribed order and in which subsequent steps may depend on information entered in previous ones. As Users enters information, XPRESSO computes the appropriate path for the user and routes them accordingly. XPRESSO uses wizards to configure (for example) Jenkins and Cloud Jobs, Job Requests, and Docker Images.

YAML: Initial definition: Yet Another Markup Language. Recursive definition: YAML Ain't Markup Language.; In XPRESSO, you describe your devices under test (your testbed) in a testbed.yaml file. The YAML file describes your physical devices and how they link together to form the testbed network topology.