Skip to content

0.29.0 never becomes ready #3419

@dgn

Description

@dgn

Bug Report

What did you do?
We regularly install the olm-operator on KinD using operator-sdk olm install. This has started failing since 0.29.0 has come out. 0.28.0 installs just fine. We're using the latest version of operator-sdk (v1.37.0)

Here's a log:

INFO[0010] Creating OLM resources...                    
INFO[0010]   Creating Namespace "olm"                   
INFO[0012]   Namespace "olm" created                    
INFO[0012]   Creating Namespace "operators"             
INFO[0013]   Namespace "operators" created              
[...snip...]
INFO[0024]   Creating CatalogSource "olm/operatorhubio-catalog" 
INFO[0025]   CatalogSource "olm/operatorhubio-catalog" created 
INFO[0025] Waiting for deployment/olm-operator rollout to complete 
INFO[0026]   Waiting for Deployment "olm/olm-operator" to rollout: 0 of 1 updated replicas are available 
FATA[0120] Failed to install OLM version "latest": deployment/olm-operator failed to rollout: context deadline exceeded 

The containers fail to start with CreateContainerConfigError. Here's the relevant event log:

  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Warning  Failed     5s (x11 over 2m1s)  kubelet            Error: container has runAsNonRoot and image will run as root (pod: "olm-operator-7b6ffc567-nnlm7_olm(5b55cb5e-8d14-4b71-abd7-8fd8644c28be)", container: olm-operator)
  Normal   Pulled     5s (x10 over 2m)    kubelet            Container image "quay.io/operator-framework/olm@sha256:cfdda06700fae2962ac89e677c1968517f8c5fae838ca31774b909f545d7be37" already present on machine

What did you expect to see?
A working installation of olm-operator using operator-sdk olm install

What did you see instead? Under which circumstances?
Deployment never becomes ready.

Environment

  • operator-lifecycle-manager version:

0.29.0

  • Kubernetes version information:

v1.29.2

  • Kubernetes cluster kind:

KinD cluster

Possible Solution
Looks like container has runAsNonRoot and image will run as root from the event log is the issue, but there might be more.

Additional context
Add any other context about the problem here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugCategorizes issue or PR as related to a bug.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions