Disclaimer

Your use of this download is governed by Stonebranch’s Terms of Use.

Version Information

Template Name	Extension Name	Extension Version	Status
OpenShift Jobs & Templates	ue-openshift-jt	(Current 1.0.0)	Fixes and new Features are introduced.

Refer to Changelog for version history information.

Overview

OpenShift is Red Hat’s enterprise Kubernetes platform for deploying, managing, and scaling containerized applications. It supports resources like Jobs, CronJobs, and Templates for handling tasks such as batch processing, scheduled workloads, and reusable application definitions.

This integration enables the deployment of OpenShift Jobs, CronJobs, and Templates, either imperatively or declaratively, along with retrieval of information pertaining to aforementioned deployments. It also supports deleting these resources from any namespace, providing flexible management across clusters.

Key Features

Feature	Description
Deploy OpenShift Resources	Deploy Job, CronJob and Template resources, either declaratively or imperatively, from local YAML or JSON files, remote URLs or UAC scripts.
Deploy Jobs from OpenShift Templates	Deploy parametrized Job instances by processing existing Template objects in the cluster.
Create Jobs from CronJobs	Create one-off Job resources based on existing CronJob definitions in the cluster.
Delete OpenShift Resources	Delete Job, CronJob and Template resources via the delete action or manually through a Dynamic Command. Job resources can also be set to be deleted automatically after completion.
Authentication Options	Supported authentication methods include Basic Authentication and Access Token Authentication.
Pod Information Streaming	Live stream real-time updates about Kubernetes pods as they are created, modified, or terminated.
Automatic or Manual Container Information Retrieval	Option to automatically or manually retrieve information, including logs, for all containers pertaining to a specific job.

Requirements

This integration requires a Universal Agent and a Python runtime to execute the Universal Task.

Area	Details
Python Version	Requires Python 3.11, tested with Python 3.11.8
Universal Agent Compatibility	Compatible with Universal Agent for Windows x64 and version >= 7.6.0.0. Compatible with Universal Agent for Linux and version >= 7.6.0.0.
Universal Controller Compatibility	Universal Controller Version >= 7.6.0.0.
OpenShift & Kubernetes	This integration is tested using Red Hat OpenShift Container Platform version 4.18, and the corresponding Kubernetes version 1.31.5. It should be compatible with later versions as long as backward compatibility is preserved.
Network and Connectivity	Connectivity towards an OpenShift Cluster.

Supported Actions

There are nine Top-Level actions controlled by the Action Field:

Apply a job definition directly to the cluster.
Apply a parameterized job using a cluster-stored template.
Apply a cronjob to schedule recurring tasks.
Create a new job using a provided specification.
Create a parameterized job based on a cluster-stored template.
Create a one-time job from an existing cronjob definition.
Create a new cronjob for scheduled task execution.
Create and store a reusable job or cronjob template in the cluster.
Delete a job, cronjob, or template by name and project.

Additional options and post action capabilities vary depending on the chosen Action.

Action Output

Output Type

Description

Examples

EXTENSION

The extension output provides the following information:

exit_code, status, status_description: General info regarding the task execution. In case of failure, it’s set according to the specific error that happened during the execution. A list of possible values is provided in the exit codes table in this document.
invocation.fields: The task configuration used for this task execution.
result.containers: Information gathered related to the containers spawned by the deployed job. Information is retrieved from the OpenShift cluster using the values appointed to the Output Only fields during execution. Only available if the corresponding Extension Output option has been selected.
result.resource_specification: Information relating to the specification of the deployed resource. Only available if the corresponding Extension Output option has been selected.

Successful Execution of "Apply Job" Action, with all Extension Output options selected

{
	"exit_code": 0,
	"status_description": "Job applied successfully.",
	"invocation": {
		"extension": "ue-openshift-jt",
		"version": "1.0.0",
		"fields": {
			...
		}
	},
	"result": {
		"containers": [
			{
				"pod_name": "pi-simple-deploy-2lns6",
				"container_name": "pi",
				"container_log": "3.1416",
				"exit_code": "0",
				"restart_count": "0"
			},
			{
				"pod_name": "pi-simple-deploy-2lns6",
				"container_name": "hello",
				"container_log": "Hello World!\n",
				"exit_code": "0",
				"restart_count": "0"
			}
		],
		"resource_specification": {
			"name": "pi-simple-deploy",
			"namespace": "extension",
			"active_deadline_seconds": 1800,
			"backoff_limit": 6,
			"completions": 1,
			"parallelism": 1,
			"pod_failure_policy": null,
			"pod_replacement_policy": "TerminatingOrFailed",
			"success_policy": null,
			"ttl_seconds_after_finished": 3600,
			"suspend": false
		}
	}
}

Failed Execution

{
	"exit_code": 21,
	"status_description": "Resource Naming Error: A job with the name pi-simple-deploy already exists in the namespace extensions",
	"invocation": {
		"extension": "ue-openshift-jt",
		"version": "1.0.0",
		"fields": {...}
	},
	"result": {
		"errors": [
			"Resource Naming Error: A job with the name pi-simple-deploy already exists in the namespace extensions"
		]
	}
}

STDOUT

The STDOUT output produced during the execution of the task instance.

Output can be controlled via the STDOUT Options input field. Available choices are:

“Enable Pod Monitoring”, which streams information about the state of pods relating to the deployed job.
“Include Container Logs” which outputs logs for all containers tied to the deployed job.

Both options are only applicable if Wait for Success or Failure has been selected.

Example of Pod Monitoring output and Container logs

--- Pod Monitoring Events for job pi-simple-deploy ---
	Event: ADDED
	Event Time: 2025-MM-DD 16:18:20 +0300
	Pod Name: pi-simple-deploy-2lns6
	Phase: Pending
	Conditions: PodScheduled
	Start Time: None

	Event: MODIFIED
	Event Time: 2025-MM-DD 16:18:21 +0300
	Pod Name: pi-simple-deploy-2lns6
	Phase: Pending
	Conditions: PodReadyToStartContainers, Initialized, Ready, ContainersReady, PodScheduled
	Start Time: 2025-MM-DD 13:18:20+00:00
	Container: hello
		Waiting:
			Reason: ContainerCreating

	Container: pi
		Waiting:
			Reason: ContainerCreating

...

Pod pi-simple-deploy-2lns6 has reached phase 'Succeeded' but is pending deletion due to finalizers

	Event: MODIFIED
	Event Time: 2025-05-09 16:18:25 +0300
	Pod Name: pi-simple-deploy-2lns6
	Phase: Succeeded
	Conditions: PodReadyToStartContainers, Initialized, Ready, ContainersReady, PodScheduled
	Start Time: 2025-MM-DD 13:18:20+00:00
	Container: hello
		Terminated:
			Exit Code: 0
			Reason: Completed
			Started at: 2025-MM-DD 13:18:22+00:00
			Finished at: 2025-MM-DD 13:18:22+00:00

	Container: pi
		Terminated:
			Exit Code: 0
			Reason: Completed
			Started at: 2025-MM-DD 13:18:21+00:00
			Finished at: 2025-MM-DD 13:18:22+00:00

Pod pi-simple-deploy-2lns6 has reached phase 'Succeeded'

Pod pi-simple-deploy-2lns6 successfully completed, 1/1 pods completed.

Job pi-simple-deploy execution finished, status is 'SuccessCriteriaMet'.

--- Logs for containers generated for job pi-simple-deploy at 2025-MM-DD 16:26:09 +0300 ---
Logs for pod pi-simple-deploy-lin-systempython-2lns6
	Logs for container pi:
		3.1416
	Logs for container hello:
		Hello World!

Configuration Examples

Example: Apply a Job Definition to the OpenShift Cluster

This configuration applies a job definition directly to the cluster using basic authentication (username and password). SSL verification is enabled with a custom certificate path. The job definition is fetched from an HTTP link, using the GIT_TOKEN environment variable for access. After the job is applied, the task waits for it to complete and deletes the job from the cluster if it finishes successfully. All output options are enabled, providing additional information on STDOUT and Extension Output.

The configuration for tasks to Create a Job on the cluster remains unchanged compared to the configuration to Apply a Job; only a different action is selected from the available fields. This is true for all deployment types.

Example: Create a Template on the OpenShift Cluster

This configuration creates a template on the cluster using token-based authentication. The resource definition is taken from a local file that resides on the agent. The ‘extensions’ project is specified, meaning the template will be created on that project, unless a different project is specified on the Template Manifest. Information about the deployed template will be shown on Extension Output. Note that while container information is checked to be retrieved, since no containers are tied to the deployment of the Template, no additional information will appear on Extension Output.

Example: Create a Job from a Template stored on the OpenShift cluster

This configuration creates a Job from a cluster-stored template using basic authentication (username and password). Input parameters are specified to customize the job described in the template. The resulting job is created on the cluster, and the task returns immediately, showing the definition of the deployed job on the Extension’s Output.

Example: Create a CronJob on the OpenShift Cluster

This configuration creates a CronJob using basic authentication (username and password), enabling SSL Verification. The Definition of the CronJob to be deployed is retrieved via HTTP Link, using the AUTH_USER and AUTH_PASS environmental variables for authentication. The OpenShift resource specification for the deployed CronJob will be visible on the Extension’s output. However, once again, container information will be omitted as no containers are tied to the deployment of the CronJob.

Example: Create a Job from a CronJob stored on the OpenShift cluster

This configuration creates a job from an existing CronJob, using Token Authentication and specifying the ‘extensions’ project. The job is going to be created based on the CronJob's specification and will have the name specified on the relevant field. The resulting Job is to be monitored, producing information on both output streams. Note that container logs are to be retrieved and displayed only in the case that the job results in failure.

Example: Delete a Resource present on the OpenShift Cluster

This configuration deletes a Template present on the OpenShift cluster. The Resource Type chosen can be a Job, CronJob, or Template. The relevant Resource Name dynamic choice field can be used to load all resources of the specified type.

Input Fields

Name	Type	Description	Version Information
Action	Choice	The action to be executed. Options: Apply Job Apply Job from Template Apply CronJob Create Job Create Job from Template Create Job from CronJob Create CronJob Create Template Delete Resource	Introduced in 1.0.0
OpenShift Server and Port URL	Text	The OpenShift Server and Port information. Ensure you specify the appropriate URL for API communication. Example: `https://api.example.openshift.com:6443`	Introduced in 1.0.0
Project	Text	The OpenShift project (namespace) in which resources are to be deployed or deleted. In the case of resource deployment, this field will be used only as a fallback in case a ‘namespace’ value is not specified inside of the Resource Definition.	Introduced in 1.0.0
Authentication Method	Choice	The Authentication Method to be used. Options: Basic Authentication Access Token	Introduced in 1.0.0
OpenShift Credentials (Basic Authentication)	Credentials	The Credentials used to login to OpenShift. The definition of the Credential should be as follows: The Username as the Credential’s “Runtime User” The Password as the Credential’s “Runtime Password” Only available if Authentication Method is set to “Basic Authentication”	Introduced in 1.0.0
OpenShift Credentials (Token Authentication)	Credentials	The credentials used to login to OpenShift. The definition of the Credential should be: The Token as the Credential’s “Token” Note that the hash algorithm prefix should be included on the token string. Only available if Authentication Method is set to “Access Token”	Introduced in 1.0.0
Enable SSL Verification	Checkbox	Enable to verify the server's SSL certificate. Disable to skip verification.	Introduced in 1.0.0
SSL Certificate Path	Text	Path to custom CA certificate. If this field is left empty, the Mozilla-maintained CA Bundle will be used.	Introduced in 1.0.0
Resource Definition Source	Choice	Specifies the source of the Job, CronJob, or Template manifest. The input must be in YAML or JSON format and must define exactly one resource. UAC Script Local File HTTP Link Available if Action is set to any of “Apply Job”, “Apply CronJob”, “Create Job”, “Create CronJob”, “Create Template”	Introduced in 1.0.0
Resource Definition Script	Script	The UAC Script containing the Resource definition. Mandatory if Resource Definition Source is set to “UAC Script”	Introduced in 1.0.0
Resource Definition File Path	Text	The Agent’s local full filename path to the Resource Definition. Mandatory if Resource Definition Source is set to “Local File”	Introduced in 1.0.0
Resource Definition Link	Text	The HTTP link that points to the Job Definition or CronJob/Template Manifest. Environment variables in the URL are resolved; The `GIT_TOKEN` environmental variable, if set, is used as a Bearer token for authorization. Mandatory if Resource Definition Source is set to “HTTP Link”	Introduced in 1.0.0
Template to Use	Dynamic Choice	The Template to use to create a new Job. Available & Mandatory if action is set to “Apply Job from Template”, “Create Job from Template”	Introduced in 1.0.0
Input Parameters	Array Field	Parameters to use when creating Job from Template. Available & Mandatory if action is set to “Apply Job from Template”, “Create Job from Template”	Introduced in 1.0.0
CronJob to Use	Dynamic Choice	The CronJob to use when creating Job from CronJob. Available & Mandatory if action is set to “Create Job from CronJob”	Introduced in 1.0.0
New Job Name	Text	The name that the created Job should have. Available & Mandatory if action is set to “Create Job from CronJob”	Introduced in 1.0.0
Resource Type	Choice	The type of Resource to be deleted. Available options are: Job CronJob Template Available & Mandatory if Action is set to “Delete Job”	Introduced in 1.0.0
Resource Name	Dynamic Choice	The name of the Resource to be deleted. Available & Mandatory if Action is set to “Delete Job”	Introduced in 1.0.0
Wait for Success or Failure	Checkbox	Choose where the UAC task should wait until the deployed Job is completed. Available if Action is set to “Apply Job”, “Apply Job from Template”, “Create Job”, “Create Job from Template”, “Create Job from CronJob”	Introduced in 1.0.0
Monitoring Timeout (sec)	Integer	The maximum number of seconds to monitor whether the job has been completed. If exceeded, a TimeoutExceededError is raised. Set to 0 to monitor indefinitely. Only available if Wait for Success or Failure is selected.	Introduced in 1.0.0
Extension Output Options	Choice	Controls whether additional information is printed to Extension Output. Available options are: Include OpenShift Resource Specification Include Container Information (Only applicable if Wait for Success or Failure is selected) Available for all actions except “Delete Job”	Introduced in 1.0.0
STDOUT Options	Choice	Controls whether additional information is printed to Standard Output. Available options are: Include Container Logs Enable Pod Monitoring Only available if Wait for Success or Failure is selected.	Introduced in 1.0.0
Delete Job Options	Choice	Specifies the conditions under which the Deployed Job should be deleted. When deploying a job from a Template or CronJob, only the job instance itself will be deleted. Available options are: Do not Delete Job Delete Job on Successful execution (default) Delete Job regardless of execution status Only available if Wait for Success or Failure is selected.	Introduced in 1.0.0
Retrieve Container Information Only on Failure	Checkbox	Specifies whether container information is only retrieved when job fails. This option does nothing if “Include Container Logs” or "Include Container Information" options are not requested as part of the Standard Output or Extension Output options respectively. Only available if Wait for Success or Failure is selected.	Introduced in 1.0.0

Output Fields

Name	Type	Description	Version Information
Resource Name	Text	Name of deployed Resource. Applicable for all Actions except “Delete Job”.	Introduced in 1.0.0
Resource Project	Text	Project (namespace) the resource has been deployed on. Applicable for all Actions except “Delete Job”.	Introduced in 1.0.0

Environment Variables

Environment Variables can be set from Environment Variables task definition table. The following environment variables can affect the behavior of the extension.

Environment Variable Name

Description

Version Information

UE_HTTP_TIMEOUT

This environment variable defines the global timeout value for all requests. It affects both connection and read timeouts, preventing requests from hanging.

Accepted values: Positive integer (in seconds).

If the environment variable is not set, or is set to an invalid value, the timeout will default to 60 seconds.

Introduced in 1.0.0.

GIT_TOKEN

If specified, this environment variable will be used as a Bearer token in the Authorization header when making the request to retrieve a Resource Definition via HTTP Link.

Introduced in 1.0.0.

Cancelation and Rerun

In case of cancellation, monitoring of the deployed job is halted. No additional actions are taken on the OpenShift Cluster. If the deployment process has already been initiated, it will not be impacted in any way.
In case of rerun the extension follows the same execution flow as the initial execution. As such, resources will be deployed or deleted, depending on the specified input fields, with no regards to the existing condition of the OpenShift Cluster.

Dynamic Commands

Command Name

Allowed Task Instance Status

Description

Delete Resource

Cancelled, Failed, Finished, Success

Deletes the deployed resource from the specified project (namespace). The name of the Job to delete, as well as the project it exists inside of, is inferred using the Resource Name and Resource Project Output Fields.

Applicable for all Actions except “Delete Job”.

Retrieve Container Logs

Running, Cancelled, Failed, Finished, Success

Retrieves all container logs associated with the deployed job that have been generated up to that point. The name of the Job to retrieve container logs for is inferred from the Resource Name and Resource Project Output Fields.

Only applicable if Action is set to “Apply Job”, “Apply Job from Template”, “Create Job”, “Create Job from Template”, “Create Job from CronJob”.

Exit Codes

Exit Code	Status	Status Description	Meaning
0	Success	“SUCCESS: Task executed successfully.“	Successful Execution
1	Failure	“Execution Failed: <<Error Description>>”	Generic Error. Raised in case of failure and in case no other failure exit code is applicable.
2	Failure	“Authentication Error: <<Error Description>>“	Bad Credentials.
20	Failure	“Data Validation Error: <<Error Description>>“	Input fields validation error.
21	Failure	“DuplicateJobNameError: Job Naming Error.”	A job sharing the provided name already exists in the specified namespace. Raised only if attempting to manage resource imperatively.
40	Failure	“TimeoutExceededError: Timeout Error.“	The number of seconds to monitor the job, specified by the Timeout Seconds field, has been exceeded.

STDOUT and STDERR

STDOUT of this integration is empty, unless additional information is requested through the STDOUT Options field.

STDERR provides additional information to the user, the verbosity of which is tuned by Log Level Task Definition field.

STDOUT and STDERR provide additional information to the User. The populated content can be changed in future versions without notice. Backward compatibility is not guaranteed.

How To

Import Universal Template

To use the Universal Template, you first must perform the following steps.

This Universal Task requires the Resolvable Credentials feature. Check that the Resolvable Credentials Permitted system property has been set to true.
To import the Universal Template into your Controller, follow these instructions.
When the files have been imported successfully, refresh the Universal Templates list; the Universal Template will appear on the list.

Modifications of this integration, applied by users or customers, before or after import, might affect the supportability of this integration. For more information refer to Integration Modifications.

Configure Universal Task

For a new Universal Task, create a new task, and enter the required input fields.

Integration Modifications

Modifications applied by users or customers, before or after import, might affect the supportability of this integration. The following modifications are discouraged to retain the support level as applied for this integration.

Python code modifications should not be done.
Template Modifications
- General Section
  - "Name", "Extension", "Variable Prefix", and "Icon" should not be changed.
- Universal Template Details Section
  - "Template Type", "Agent Type", "Send Extension Variables", and "Always Cancel on Force Finish" should not be changed.
- Result Processing Defaults Section
  - Success and Failure Exit codes should not be changed.
  - Success and Failure Output processing should not be changed.
- Fields Restriction Section
  The setup of the template does not impose any restrictions. However, concerning the "Exit Code Processing Fields" section.
  1. Success/Failure exit codes need to be respected.
  2. In principle, as STDERR and STDOUT outputs can change in follow-up releases of this integration, they should not be considered as a reliable source for determining the success or failure of a task.

Event Template configuration related to “Metric Label Attributes” & “Optional Metric Labels” is allowed. However, administrators should be cautious of high cardinality scenarios that might occur.

Users and customers are encouraged to report defects, or feature requests at Stonebranch Support Desk.

Document References

This document references the following links:

Document Link	Description
Universal Templates	User documentation for creating, working with and understanding Universal Templates and Integrations.
Universal Tasks	User documentation for creating Universal Tasks in the Universal Controller user interface.

Changelog

ue-openshift-jt-1.0.0 (2025-05-22)

Initial Release

Red Hat: OpenShift Jobs & Templates

Disclaimer

Version Information

Overview

Key Features

Requirements

Supported Actions

Action Output

Configuration Examples

Example: Apply a Job Definition to the OpenShift Cluster

Example: Create a Template on the OpenShift Cluster

Example: Create a Job from a Template stored on the OpenShift cluster

Example: Create a CronJob on the OpenShift Cluster

Example: Create a Job from a CronJob stored on the OpenShift cluster

Example: Delete a Resource present on the OpenShift Cluster

Input Fields

Output Fields

Environment Variables

Cancelation and Rerun

Dynamic Commands

Exit Codes

STDOUT and STDERR

How To

Import Universal Template

Configure Universal Task

Integration Modifications

Document References

Changelog

ue-openshift-jt-1.0.0 (2025-05-22)