XPRESSO

Operational and Configuration States

About Operational and Configuration States

XPRESSO constantly monitors all equipment and resources to report the followings states (status) of the object):

Operational states: Reports the current active state of the object being viewed.

EXAMPLE:
As a Job transitions through the stages of a Job Run, XPRESSO reports the operational states from four main perspectives:

Prior to commencing a Job Run, XPRESSO reports the readiness or availability of an object, for example: Online/Enabled/Free, Busy/Offline, or Available/Unavailable.
Once a Job Run starts, XPRESSO reports the transitional states as the Job Run executes, for example: Active, Preparing, Queuing, or Orchestrating.
After the Job Run completes, XPRESSO reports what happened with the Job Run, for example: Passed, Passed with Exception, or Success.
In the event a Job Run fails to execute, XPRESSO reports the reason(s) why, for example: Aborted, Errored, Failed, or Stopped.

Refer to the Operational States table below for a description of each state associated with each object type.

Configuration states: Reports the current configuration status of supported objects configured by users. Supported states are: Enabled (default configuration state), Disabled, and Maintenance. Group Admins (or permitted users) can change the configuration state of the objects for specific testing requirements.

Why Operational States Matter?

Provides a real-time, at-a-glance readiness of downstream test equipment and resources. Knowing the availability of your test environment (such as status of your testbed and Execution engine) helps determine the stability and availability of your test automation ecosystem before usage.

EXAMPLE:
For Execution Engines, you can determine if they are Online/Offline; for a Testbed, you can determine if they are currently Available, Free, Enabled, or Busy.

From a reactive perspective, you can also view/use operational state information to help you determine what caused the problem in the event your Job ran into an unexpected problem or to troubleshoot any other system-related problems.

One underlying advantage of knowing the Operational State of objects is for Group Administrators to have a holistic view of their test resource usage, therefore giving them the ability to manage their resources accordingly. For example, if you know the capacity of your current testbed exceeds your testing requirements, you can then take the appropriate action to offload some of the testing requirements onto a secondary testbed to get better load-balancing.

How Operational States are Determined?

The Operational state of an object is derived by considering a number of related attributes such as:

Monitoring the communication links between XPRESSO, your test environment, and your devices.
Tracking all related Job execution data within XPRESSO such as reservation and scheduling details (who, what, when, and on which testbed), and the equipment configuration state and location details, etc.

Defining Operational States

XPRESSO reports the following operational states on supported object types (this table is presented in alphabetical order based on the Operational State Name):

NOTE:
Operational states are set and updated automatically by the system; you cannot configure an operational state.

State	Applicable Object	Description
Aborted	Job Results	Indicates that that Job Run did not run to completion. The common reasons for termination is due to a script issue, a clean failure, or an external factor such as a power outage.
Active	Reservations	Indicates that the testbed is being used by the current reservation.
Awaiting Resources	Job Requests Testbeds	Job Requests: Indicates that a request to run on a topology was initiated by the user. Since the testbed is not available yet, the request cannot move forward. Testbeds: Indicates that a dynamic testbed is requested from a topology and the testbed is not available. The testbed is waiting for a valid YAML file to be orchestrated by the LaaS-NG.
Available	Testbeds	Indicates that a testbed is currently free; if you add a Job to this testbed, it will run based on where the Job sits in the Job priority queue.
Busy	Testbeds	Indicates that the testbed is busy running another Job; if you add a Job to this testbed, it will first complete the Job that is running and then be subject to the queuing rules that apply to the testbed.
Building	Docker (Cloud) Images	Indicates that a custom Docker (Cloud) image is currently being built.
Different	Result Differences Baseline Comparison	Indicates that the current Job test results are different when compared against the baseline Job test results.
Errored	Job Requests Job Results Reservations Docker (Cloud) Images	Job Requests/Results: Indicates that an error occurred with the Job Request/Job Results during a Job Run. You can view the reason(s) for the error on the Job Request/Job Results details page. You can view any execution statistics recorded before the error if applicable or available. Reservations: Indicates if an error occurred during any other object allocation states. Docker (Cloud) Images: Indicates that one of the services associated with the Docker Image is currently unavailable when registering the Image (OR) Indicates a Docker Image pull failure.
Expired	Reservations Job Requests	Reservation: Indicates that the reservation schedule duration ended (OR) the specified end date/time was reached (OR) the reservation was cancelled from the LaaS-NG UI. Job Requests: Indicates that the Job Request could not be completed within the defined maximum Job Request lifetime/maximum runtime or could not be dispatched within the maximum queue retention lifetime. When the Job Request Expires, it will be terminated or cleared off the priority queue. (OR) The Job Request has a maximum lifetime regardless of what happens downstream (therefore, the Job Request could be queued or run endlessly). If the Job Request crosses the lifetime period threshold, it is set to Expired.
Failed	Job Requests Job Results Docker (Cloud) Images	Job Requests/Results: Indicates that the Job execution completed but contains elements that contains incomplete statistics. You can view the reason for the stoppage on the Job Request/Job Results details page. You can view any execution statistics recorded before the stop if applicable. (OR) There is at least one test case failure in the Job Run. Docker (Cloud) Images: Indicates that the Docker Image details contains invalid user profile data and cannot be validated (OR) The pre-existing Docker Image cannot be registered in XPRESSO since it contains invalid data requirements or structure.
Free	Testbeds	Indicates that a testbed is currently free and you can run your Job immediately.
Offline	Execution Engines	Indicates the Execution Engine is not connected; if you add a Job Run on this engine, it will error.
Online	Execution Engines	Indicates the Execution Engine is connected; you can perform a Job Run on this engine.
Orchestrating	Reservations	Indicates that XPRESSO is performing the backend orchestration for your reservation.
Outdated	Docker (Cloud) Images	Indicates that the Docker Image details contains information that is out-of-date when compared against the registered Docker Image.
Passed	Job Requests Job Results	Indicates the Job Request/Job Results was completed/compiled with passed statistics. You can view the execution results on the Job Request details page.
Passed with Exception	Job Results	Indicates the Job Request/Job Results was completed with Passed statistics, however there are anomalies in the test results that required further analysis.
Preparing	Job Requests Reservations	Indicates that an object is currently being submitted.
Pulling	Docker (Cloud) Images Reservations	Docker (Cloud) Images: Indicates that a pull request associated with a Docker Image is in progress. Reservations: Indicates that a reservation has been submitted and is in progress.
Queued	Job Requests Reservations	Indicates that a Job Request or Reservation has been added to the testbed queue and will execute at the prescribed schedule time or will remain in the priority queue until its maximum queue retention period is reached. If a Job Request is submitted to be queued on multiple testbeds at the same time, the first available testbed will be used.
Queuing	Job Requests Reservations	Indicates that a Job Request or Reservation is currently being added to the testbed queue.
Registering	Docker (Cloud) Images	Indicates that a Docker Image is being registered in XPRESSO.
Released	Reservations Testbeds	Indicates that a reservation has been deleted and the testbed is available.
Releasing	Reservations	Indicates the transitional state between when a request is made to release a reservation to when the reservation is actually released.
Reserved	Testbeds	Indicates that a reservation time slot was requested for a testbed and accepted by XPRESSO as a valid request and queued according to the queuing rules.
Revoked	Reservations	Indicates that a reservation has been deleted by someone else in your Group other than the Group Member who created the reservation.
Running	Job Requests Docker (Cloud) Images	Job Request: Indicates that a Job Request is currently executing and will provide Job Results once it completes; each Job Request is limited to a maximum runtime defined in the Job Profile. Docker (Cloud) Images: Indicates that a custom Docker image is currently being built to provide the required Job execution backend.
Skipped	Job Results	Indicates that the Job Run successfully completed but the compilation of Job Results was skipped due to errors.
Stopped	Job Requests Job Results	Indicates that the Job Request/Job Results was stopped during the Job Run. You can view the reason for the stoppage on the Job Request/Job Results details page. You can view any execution statistics recorded before the stop if applicable.
Submitted	Docker (Cloud) Images	Indicates that a Docker Image has been submitted to XPRESSO for registration.
Success	Docker (Cloud) Images	Indicates that a fully configured/compliant Docker image has been successfully registered in XPRESSO; you can now execute a Job Run using your Cloud Image.
Unavailable	Reservations	Indicates that the chosen time slot is currently reserved and therefore unavailable.

Why Configuration States Matter?

XPRESSO provides the ability to control the availability of registered objects by changing it's configuration state.

Some examples of how you can exploit this feature:

You can disable a registered object thus taking away its availability for use by other users.
You can place a registered object into Maintenance mode in order to restrict its use so the Group Admin can perform troubleshooting.
You can temporarily disable a testbed and stack (queue) your Job Run against the Disabled test bed in anticipation of reactivating the testbed when your resource availability is less restrictive, for example, performing your Job Runs over a weekend.
You may be running multiple Job Runs across several test beds with slightly different configurations; you can disable one or more of the testbeds to force the Job Run to use a specific testbed.

Defining Configuration States

You can change the configuration state of supported objects to one of the following three states:

Enabled: This is the default state when an object is create/registered in XPRESSO. Objects in an Enabled state are active and accessible for all Members within the same Group.
Disabled: Allows you to temporarily disable an object from being used. Job Runs can still be assigned to the disabled object but will not execute until the object is Enabled.
Maintenance: This state has the same attributes as an object in a Disabled state except Group Admins and System Admins are able to use them to troubleshoot or leverage them in emergency cases.

Rules that Apply to Configuration States

The following rules apply when you set the configuration state of an object:

Changes made to a configuration State are immediate; the following applies:
- Any actions currently executing against an object such as an active Job Runs are allowed to complete.
- Any future actions that you configured against an object such as queued reservations/Job Runs will wait until the object transitions back to an Enabled state.

NOTE: For any Run Request that are in transient, the Queue Retention and Job Request lifetime parameters still apply so if they expire, any Job Requests would also expire.

Changes made to a configuration state is also reflected in the operational state of the object.

EXAMPLE:
When you change the configuration state of a testbed from Enabled to a Maintenance, the configuration state would reflect Maintenance (Busy). Once the Job completes, the configuration state would reflect Maintenance (Free).

When you change the configuration state of an object, you are prompted to provide a reason for the change as part of the confirmation; this information is recorded in the history log.

Viewing or Setting the Configuration State of an Object

You can view the configuration state of a object in the Config State column on the objects details page.

Group Admins (or permitted users) can also change the current state to another state by clicking on the appropriate configuration state button (Enable | Maintenance | Disable). Enter a reason for the change when prompted and click the Set button.

See the Group Administration topic for information about how to change the configuration state of a Group.

Defining Operational and Configuration States Color Usage

All operational and configuration states are associated with a color scheme to provide a visual cue to help you determine the current state of an object. The following table defines the color schemes used on the XPRESSO dashboard:

NOTE 1:
When the same color displays on the same page on the XPRESSO dashboard, they are represented with different shades to denote a difference between the states. For example: Failed and Error states are different shades of red; likewise, Aborted and Skipped states are different shades of purple.
NOTE 2:
You will notice a combined state regarding each resource/environment item as restricted by the current operational state, reservation state and configuration state of an object. You need to be aware that this combined state determines whether the resource/environment is currently usable for Job Runs. The combined state "color" code will be indicated in front of each item name.

Object type	Color Scheme
Object type	Green	Amber	Red	Special Cases
Configuration State Colors Apply to all Supported Objects
	Online (or) Enabled	Maintenance	Disabled (or) Deleted	—
Operational State Colors
Docker (Cloud) Images	Successful	Initial	Failed	Blue: In Progress or Running
Execution Engines	Online	—	Offline	—
Job Requests	Passed	Queuing Queued	Failed Errored	Blue: Running Purple: Stopped or Expired Pink: Preparing
Job Results	Passed Passed with Exception	—	Failed Errored	Purple: Aborted or Skipped Grey: Stopped Black: Blocked
Reservations	Active	Queuing Queued Releasing	Revoked Unavailable Errored	Black: Released Blue: Orchestrating Pink: Preparing Purple: Expired
Result Differences	Matched Added	—	Different Missing	—
Testbeds Topologies	Free Available	Awaiting Resources	Offline	Blue: Busy or Reserved Grey: Released