-
Bug
-
Resolution: Unresolved
-
Major
-
4.19
-
None
-
Quality / Stability / Reliability
-
False
-
-
None
-
Important
-
None
-
None
-
None
-
None
-
Proposed
-
None
-
-
None
-
None
-
None
-
None
Description of problem:
When a Job is manually started via the OpenShift Console's using "Start Job" functionality, its spec.backoffLimit is unexpectedly set to 6, even if the underlying Job definition or template is configured with backoffLimit: 0. In contrast, when the same Job is manually initiated via the oc CLI, it correctly adheres to the backoffLimit: 0 specified in its configuration. This behavior creates an inconsistency, where the console's manual trigger overrides explicit configuration.
Version-Release number of selected component (if applicable):
4.19.Z
How reproducible:
100%
Steps to Reproduce:
1. Manually start the Job via the OpenShift Console. Go to "Workloads" -> "Jobs" and click the "Start Job" 2. Note the name of the new Job run generated by the console and check the backofflimit paramater. (It is giving 6)
Actual results:
The newly created Job run shows backoffLimit: 6, overriding the configured in the base definition.
Expected results:
It should obey the defined backofflimit in the job.
Additional info:
- From the CLI it is working as expected --> whatever the backofflimit is define job is obeying that - From the console it is getting "backofflimit: 6" 1. Job created manually via cli. $ oc get job image-pruner-29210400 -o yaml | grep -i backofflimit backoffLimit: 0 2. Job created manually via console $ oc get job image-pruner-1752640975985 -o yaml | grep -i backofflimit backoffLimit: 6
- blocks
-
OCPBUGS-60294 OpenShift Console's "Start Job" action overrides configured "backoffLimit" to "6"
-
- Closed
-
- is cloned by
-
OCPBUGS-60294 OpenShift Console's "Start Job" action overrides configured "backoffLimit" to "6"
-
- Closed
-
- links to