Agent provisioning
When running in Kubernetes, Step supports automatic provisioning of Agents (i.e. automatic provisioning of the containers responsible for executing Keywords). This page explains how to utilize Agent provisioning in Plans.
For information on enabling or configuring Agent provisioning, please refer to the Agent Provisioning configuration page.
How it works
In a nutshell, the automatic Agent provisioning works as follows:
- Upon execution, Plans are scanned to determine the required Agents for execution
- Based on the calculation and the available Agent pools, the optimal number of Agents per Agent pool is calculated
- The required Agents are provisioned
- Once the Agents have joined the grid, the execution starts
- After execution, the agents are de-provisioned
Configure provisioning settings in Plans
When Agent provisioning is enabled in Step, users can configure the Agent provisioning settings in each plan (in the UI and in the automation packages). By default, the Agent provisioning is configured to automatically determine and provision the Agents. This can be changed on a Plan basis.
Configure provisioning settings in the UI
In the Plan editor, the Agent provisioning settings can be accessed using the following button:
From here, you can:
- enable or disable automatic determination and provisioning of agents
- if automatic provisioning is disabled, you can manually define the number of Agents per available agent pool
If the automatic determination of Agents is enabled, Step scans the Plans upon execution and automatically determines the required agents as explained below in detail.
If you’ve disabled the automatic determination of Agents, you can manually specify the Agents to be provisioned upon execution:
- Agent pools: the agent pools listed when clicking “Add agent pool” corresponds to the list of configured pool templates
- Replicas: specifies the number of agents to be provisioned
- Image: optionally specifies the Docker image to be used for the pool. Refer to Creating your own Agent images for details on how to create custom images.
Configure provisioning settings in Yaml
In the YAML descriptor of Automation Packages, the provisioning settings can be defined for each Plan using the agents
field as follows:
---
schemaVersion: 1.0.0
name: "my-automation-package"
plans:
- name: "OpenCart okhttp Load Test"
agents:
- pool: java-enterprise-agent
replicas: 2
image: docker-dev.exense.ch/test:agent-java-custom
Refer to the Automation Package descriptor for more details.
Auto-determination of Agents
How it works
When the automatic determination of Agents is enabled, Step scans the Plans upon execution and automatically determines the required agents.
As Step Plans can be complex and make use of dynamic expressions to control workflows, the determination of the agents is not just a static analysis of the Plan, but requires evaluation of expressions. In most cases, the automatic determination works well and is able to determine the optimal agents. There’s however special cases where the automatic determination cannot precisely determine the agents. In such cases, users can disable the automatic mode and manually specify the agents they need to execute the plan.
Examples
The auto-determination of Agents is based on the Plan and can be best explained with some concrete examples:
Let’s assume a simple Plan (TestCase for instance) that calls a few Java Keywords in sequence. For the execution of this Plan, 1 Java Agent token is required. If the available agent pools contain 1 Java agent pool configured with 1 agent token per agent, the automatic provisioning would determine that 1 Agent of the Agent pool is required for the execution and provision it accordingly.
If we now have a TestSet Plan with 2 TestCases, each one calling a few Java Keywords, and the TestSet is configured to run in parallel with 2 Threads, the execution of the Plan would require 2 Java Agent tokens. In this case 2 agents from the Java agent pool would be provisioned automatically.
This works similarly for other kind of controls and keywords.
Routing criteria
It is common to have different Agent pools with different sizing or settings for the same agent type. In order to match the right pool, users can define Keyword routing rules in their Plans.
These Keyword routing rules are also considered for the determination of the agents.
Assuming that 2 Java agent pools are configured as follows:
agent:
pools:
- name: "java-ui-testing"
agentProvisioningTemplate: "true"
config:
properties:
tokenGroups:
- capacity: 1
tokenConf:
attributes:
tech: java
type: ui-testing
- name: "java-api-testing"
agentProvisioningTemplate: "true"
config:
properties:
tokenGroups:
- capacity: 10
tokenConf:
attributes:
tech: java
type: api-testing
Users might define routing criteria in their Plan as follows to match a specific agent pool:
The automatic provisioning would determine that the pool “java-api-testing” is required and provision it automatically.
Reporting of provisioning status and logs
Upon execution, agents are provisioned automatically by the provisioning engine according to the defined settings.
The provisioning status and the related logs are displayed on the execution report:
Expanding the section displays all the provisioning details (Kubernetes events per pool, Kubernetes events and logs of each provisioned container)
Deprovisioning
At execution end or in case of any error, the agents that where provisioned by the provisioning engine are automatically destroyed.