What did you see instead? Under which circumstances?
Installation of the operator failed and an error was returned
time="2024-07-22T06:03:01Z" level=error msg="failed to get a client for operator deployment - the service account does not have any API secret sa=npv-dev-34/some-ansible-operator"
Environment
operator-lifecycle-manager version:
$ oc get csv packageserver -n openshift-operator-lifecycle-manager
NAME DISPLAY VERSION REPLACES PHASE
packageserver Package Server 0.0.1-snapshot Succeeded
Kubernetes version information:
OpenShift v4.16
$ oc version
Client Version: 4.16.0-202406052127.p0.ga245041.assembly.stream-a245041
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: 4.16.0
Kubernetes Version: v1.29.5+29c95f3
$
Kubernetes cluster kind:
Possible Solution
When a user attempts to install an operator, the Operator Lifecycle Manager should be able to create a service account token by making a request against the Token Request API if it can not find the service account token secret associated with the target service account.
Additional context
Versions of Kubernetes prior to v1.22 automatically created credentials for accessing the Kubernetes API which would be stored in a secret with a similar name as the service account. The secrets would be mounted onto pods and used to access the Kubernetes API.
However, since Kubernetes v1.24, credentials are acquired directly from the Token Request API and mounted onto pods via a projected volume.
OchiengEd
commented
3 weeks ago
Bug Report
What did you do?
An attempt was made to install an operator.
What did you expect to see?
The operator would install successfully.
What did you see instead? Under which circumstances?
Installation of the operator failed and an error was returned
Environment
OpenShift v4.16
Possible Solution
When a user attempts to install an operator, the Operator Lifecycle Manager should be able to create a service account token by making a request against the Token Request API if it can not find the service account token secret associated with the target service account.
Additional context Versions of Kubernetes prior to v1.22 automatically created credentials for accessing the Kubernetes API which would be stored in a secret with a similar name as the service account. The secrets would be mounted onto pods and used to access the Kubernetes API.
However, since Kubernetes v1.24, credentials are acquired directly from the Token Request API and mounted onto pods via a projected volume.