Bug 2065840 - the cronjob object is created with a wrong api version batch/v1beta1 when created via the openshift console
Summary: the cronjob object is created with a wrong api version batch/v1beta1 when c...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.8
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.11.0
Assignee: Robb Hamilton
QA Contact: Xiyun Zhao
: 2067013 2069539 (view as bug list)
Depends On:
Blocks: 2106385
TreeView+ depends on / blocked
Reported: 2022-03-18 20:37 UTC by samy
Modified: 2022-08-10 10:55 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Last Closed: 2022-08-10 10:54:40 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift console pull 11216 0 None open Bug 2065840: Fix CronJob resource version to batch/v1 2022-03-22 15:07:11 UTC
Github openshift console pull 11662 0 None open Bug 2065840: redirect v1beta1 CronJobs 2022-06-07 16:02:32 UTC
Red Hat Product Errata RHSA-2022:5069 0 None None None 2022-08-10 10:55:14 UTC

Description samy 2022-03-18 20:37:03 UTC
Description of problem:
the cronjob object is using the old apiversion when its  created  via the  openshift console

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create a cronjob object yaml with batch/v1  as  the apiVersion 
2. apply the cronjob via the opensfhit console
3. notice the change in the apiversion from batch/v1  to batch/v1beta1

Actual results:
The  api version is changed from batch/v1  to batch/v1beta1

Expected results:
Since the api version batch/v1beta1 is no longer supported in ocp 4.8  the api version should be batch/v1 even in the openshift console.

Additional info:
when getting the object via  the CLI  the api version is  correct  however the problem is  with the console, it seems that the console is using a  template where the batch/v1beta1 is hardcoded [1]

[1] https://github.com/openshift/console/blob/release-4.8/frontend/public/models/yaml-templates.ts#L272-L289

Comment 2 Jakub Hadvig 2022-03-24 07:33:44 UTC
*** Bug 2067013 has been marked as a duplicate of this bug. ***

Comment 3 Jakub Hadvig 2022-03-29 10:11:21 UTC
*** Bug 2069539 has been marked as a duplicate of this bug. ***

Comment 7 Xiyun Zhao 2022-04-08 10:35:49 UTC
Hi jhadvig

Could you help to confirm if currently console is allow user to create CronJob with apiversion batch/v1beta1
  If yes, could you help to check below scenario, which is a URL would be navigated to /batch~v1beta1~CronJob/XXX page that is incorrect
(A .gif file is added on attachment for more details)

Additional Info:
This issue is only happened when user go back to 'CronJobs' page by using breadcrumb navigation menu after create a CronJob with 'v1beta1' apiversion

Reproduce step:
1. Login to OCP and navigate to developer perspective
2. Navigate to Search page, choose 'CronJob' on the dropdown list of 'Resources', and click 'add to navigation'
3. Navigate to 'CronJobs' page, create cronjobs with below YAML
apiVersion: batch/v1beta1
kind: CronJob
  name: example
  schedule: '@daily'
            - name: hello
              image: busybox
                - /bin/sh
                - '-c'
                - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
4. On the created CronJob details page -> YAML Tab, check the apiversion for the YAML
5. Go back to CronJobs page by using the navigation bar
6. Click 'Create CronJob' again
7. Check the YAML file that shown on create CronJob page
8. Check the existing CronJob that with apiversion 'batch/v1'

Actual Result:
4. CronJob can be created successfully with apiversion 'batch/v1beta1'
5. The navigation URL for 'CronJobs' is redirect to https://<my console>/k8s/ns/<namespace>/batch~v1beta1~CronJob
7. The sample YAML file is incorrect with below format:
apiVersion: batch/v1beta1
kind: CronJob
  name: example
  namespace: test
spec: {}
8. The existing CronJob apiversion will change to 'batch/1beta1' which is incorrect 

Expected Result:
4. 'batch/v1beta1' should replace with 'batch/v1' automatically when user create CronJob with 'v1beta1' on the created cronjob page
5. The navigation URL of https://<my console>/k8s/ns/<namespace>/batch~v1beta1~CronJob should not exist
7. The sample YAML file should as same as the one on administrator perspective
8. The change should not impact other CronJob

Comment 9 Robb Hamilton 2022-06-07 16:09:51 UTC
@xiyuzhao@redhat.com, I opened https://github.com/openshift/console/pull/11662 to address the problem noted in https://bugzilla.redhat.com/show_bug.cgi?id=2065840#c7.

Comment 12 Xiyun Zhao 2022-06-14 07:43:17 UTC
This bug has been verified on payload 4.11.0-0.nightly-2022-06-11-054027

Verification Step: 
1. Login OCP as administrator
2. Create a cronjob object YAML with batch/v1 as the apiVersion at Administrator and developer perspective, and apply the cronjob via the OpenShift console
3. Notice the change in the API version from batch/v1 to batch/v1beta1

3. The default API version for CronJob is batch/v1. 
   If a user provides the old API version like batch/v1beta1, UI will automatically update the YAML to batch/v1 after creating

Comment 16 Jakub Hadvig 2022-06-17 13:24:27 UTC
Given its severity of `medium` and the fact that Version is 4.8, which is in maintenance support, I dont think we should backport the issue all the way down to 4.8.
During the Maintenance Support phase, qualified Critical and Important Security Advisories (RHSAs) and Urgent and Selected High Priority Bug Fix Advisories (RHBAs) may be backported.

Comment 18 errata-xmlrpc 2022-08-10 10:54:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.