operator-sdk run bundle stopped working after changing user in Dockerfile

[Deixx]

After PR #982 was merged operator-sdk run bundle stopped working.

INFO[0008] Successfully created registry pod: registry-my-operator-bundle-v0-0-1
INFO[0008] Created CatalogSource: my-operator-catalog
INFO[0008] OperatorGroup "operator-sdk-og" created
INFO[0008] Created Subscription: my-operator-v0-0-1-sub
FATA[0600] Failed to run bundle: install plan is not available for the subscription my-operator-v0-0-1-sub: timed out waiting for the condition

# kubectl logs pod/registry-my-operator-bundle-v0-0-1
mkdir: can't create directory '/database': Permission denied

Looks like USER 1001 does not have permission to create directories.

Changing opm version in registry pod from latest to v1.23.0 allowed for pod successful start.

[sthaha]

This blocks our CI that relies on run bundle. Any workarounds for this until the bug is fixed?

[joelanford]

As a workaround, can you try specifying --index-image=quay.io/operator-framework/opm:v1.23.0 in the run bundle invocation?

[sthaha]

Thank you! pinning the index-image does fix it!

[pohly]

I also ran into this.

So even if operator-sdk is pinned to a fixed, known-good version (which we do in PMEM-CSI), it will then still pull random versions of other components (like this quay.io/operator-framework/opm image) at runtime? That sounds like a major deficiency in the release process for operator-sdk: I expect a released version to be fully deterministic.

[cniackz]

I was running into the same issue:

$ operator-sdk run bundle quay.io/cniackz4/minio-operator:v4.4.17
INFO[0056] Successfully created registry pod: quay-io-cniackz4-minio-operator-v4-4-17 
INFO[0056] Created CatalogSource: minio-operator-catalog 
INFO[0056] OperatorGroup "operator-sdk-og" created      
INFO[0056] Created Subscription: minio-operator-v4-4-17-sub 
FATA[0120] Failed to run bundle: install plan is not available for the subscription minio-operator-v4-4-17-sub: timed out waiting for the condition 

Where the logs were showing:

mkdir: can't create directory '/database': Permission denied

I applied the flag --index-image=quay.io/operator-framework/opm:v1.23.0 and it worked:

$ operator-sdk run bundle quay.io/cniackz4/minio-operator:v4.4.17 --index-image=quay.io/operator-framework/opm:v1.23.0
INFO[0013] Successfully created registry pod: quay-io-cniackz4-minio-operator-v4-4-17 
INFO[0013] Created CatalogSource: minio-operator-catalog 
INFO[0013] OperatorGroup "operator-sdk-og" created      
INFO[0013] Created Subscription: minio-operator-v4-4-17-sub 
INFO[0016] Approved InstallPlan install-n8trk for the Subscription: minio-operator-v4-4-17-sub 
INFO[0016] Waiting for ClusterServiceVersion "default/minio-operator.v4.4.17" to reach 'Succeeded' phase 
INFO[0016]   Waiting for ClusterServiceVersion "default/minio-operator.v4.4.17" to appear 
INFO[0032]   Found ClusterServiceVersion "default/minio-operator.v4.4.17" phase: Pending 
INFO[0033]   Found ClusterServiceVersion "default/minio-operator.v4.4.17" phase: InstallReady 
INFO[0036]   Found ClusterServiceVersion "default/minio-operator.v4.4.17" phase: Installing 
INFO[0055]   Found ClusterServiceVersion "default/minio-operator.v4.4.17" phase: InstallReady 
INFO[0056]   Found ClusterServiceVersion "default/minio-operator.v4.4.17" phase: Installing 
INFO[0057]   Found ClusterServiceVersion "default/minio-operator.v4.4.17" phase: Succeeded 
INFO[0057] OLM has successfully installed "minio-operator.v4.4.17" 

Thank you guys, and hopefully this is going to be solved in latest and greatest version 👍

[kaovilai]

Can everyone confirm if latest work for them again? I think it is working now.. at least for operator-sdk downloaded from relases

https://github.com/operator-framework/operator-sdk/releases/download/v1.23.0/operator-sdk_darwin_arm64

[kaovilai]

looking at the pod in the namespace generated.. it's still using opm:latest image but just wanted to note here.

[sthaha]

It "works" for us but we we now have a new problem that is related to FBC ( configmap) supporting only a max of 1 MB.

[sarroutbi]

Hello. What is the status of this issue? Is it expected to be fixed in the short term? Should we start pinning our deployments to the correct opm version (v1.23.0)?