Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Operator installation fails when using imagePullSecret linked to the default service account #1820

Closed
srinivasannanduri opened this issue Oct 20, 2020 · 1 comment · Fixed by #1863
Labels
triage/unresolved Indicates an issue that can not or will not be resolved.

Comments

@srinivasannanduri
Copy link

Bug Report

What did you do?
We are working on an operator that installs via OLM and the images are from a private registry. The operator uses default Service Account (in CSV). Hence, we create a (secret) imagePullSecret to our private image registry and link it to the 'default' service account before we install the operator. The deployment of the operator, updates the default Service Account and removes the linked imagePullSecret from the ServiceAccount. This causes the deployment of the operator to fail. Once we recreate the secret and the link to the Service Account and following it up with pod recreation [delete the pod (for reconcile to happen), the recreated pod just picks it up right] it works. When we define a Service Account and use the one that we created, the issue doesn't appear

What did you expect to see?
Operator deployment succeeds with the given imagePullSecret in default service account

What did you see instead? Under which circumstances?
Deployment of the operator failed

Environment
v1.0.0

  • Kubernetes version information:
  oc v3.11.0+0cbc58b
    kubernetes v1.11.0+d4cacc0
    features: Basic-Auth
    kubernetes v1.18.3+6c42de8
  • Kubernetes cluster kind:
    Openshift

Possible Solution

Additional context
Add any other context about the problem here.

@stale
Copy link

stale bot commented Dec 19, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Dec 19, 2020
@openshift-ci-robot openshift-ci-robot added triage/unresolved Indicates an issue that can not or will not be resolved. and removed wontfix labels Dec 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/unresolved Indicates an issue that can not or will not be resolved.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants