Description of problem: On an upgraded cluster found the following deprecated api 1.25 call for virt-cdi-controller/v0.0.0 (linux/amd64) kubernetes/$Format: ============= {'kind': 'Event', 'apiVersion': 'audit.k8s.io/v1', 'level': 'Metadata', 'auditID': '728c199f-df42-4a91-b737-3087e5e904f5', 'stage': 'ResponseComplete', 'requestURI': '/apis/batch/v1beta1/cronjobs?allowWatchBookmarks=true&resourceVersion=2850743&timeoutSeconds=423&watch=true', 'verb': 'watch', 'user': {'username': 'system:serviceaccount:openshift-cnv:cdi-sa', 'uid': '1afaedfa-cfd5-4713-8ec0-020ba0e4f05b', 'groups': ['system:serviceaccounts', 'system:serviceaccounts:openshift-cnv', 'system:authenticated'], 'extra': {'authentication.kubernetes.io/pod-name': ['cdi-deployment-6cdb55fbf7-l6xlp'], 'authentication.kubernetes.io/pod-uid': ['5d9a30a6-d0a9-45a5-9677-c47ba28b8a8a']}}, 'sourceIPs': ['10.1.156.7'], 'userAgent': 'virt-cdi-controller/v0.0.0 (linux/amd64) kubernetes/$Format', 'objectRef': {'resource': 'cronjobs', 'apiGroup': 'batch', 'apiVersion': 'v1beta1'}, 'responseStatus': {'metadata': {}, 'code': 200}, 'requestReceivedTimestamp': '2022-08-10T13:48:36.234802Z', 'stageTimestamp': '2022-08-10T13:49:00.776506Z', 'annotations': {'authorization.k8s.io/decision': 'allow', 'authorization.k8s.io/reason': 'RBAC: allowed by ClusterRoleBinding "cdi-sa" of ClusterRole "cdi" to ServiceAccount "cdi-sa/openshift-cnv"', 'k8s.io/deprecated': 'true', 'k8s.io/removed-release': '1.25'}} ============= This cluster went through the following upgrade path: 4.9.44(OCP)/4.9.5(CNV) → 4.10.25(OCP)/4.10.3-22(CNV) → 4.11.0-rc.5(OCP)/4.11.0-587(CNV) Version-Release number of selected component (if applicable): 4.11.0-rc.5(OCP) 4.11.0-587(CNV) How reproducible: Seen against 1 run. Steps to Reproduce: 1. Upgrade a cluster from 4.9.z->4.10.z->4.11.0 and check for deprecated API log messages in audit.log 2. 3. Actual results: Deprecated 1.25 API call Expected results: No Deprecated 1.25 API call Additional info:
virt-cdi-controller appears to be related to kubevirt/cdi project and hence moving this to the Storage Component.
Alex, if someone upgrades a cluster from 4.10 all the way through 4.12 would we have a problem or are the outdated cronjobs replaced with newer ones?
(In reply to Adam Litke from comment #3) > Alex, if someone upgrades a cluster from 4.10 all the way through 4.12 would > we have a problem or are the outdated cronjobs replaced with newer ones? So we'll create new cron jobs whenever they do not already exist. This happens since we introduced the feature (4.10). Or did you mean we should do the conversion from existing beta ones to v1 ones ourselves in 4.11? @alitke
I am wondering what happens to the preexisting old objects. Yan has created an issue to test this behavior so we will know what to expect.
Test on upgrade cluster (4.10 -> 4.11 -> 4.12), cronjob works well and not see the deprecated api error in audit log
Verified the bug according to #Comment8
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 Virtualization 4.12.0 Images 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. https://access.redhat.com/errata/RHSA-2023:0408
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days