Installation on minikube 1.13.0 does not pull in packages from the default catalog source

[jdob]

Bug Report

What did you do?
I installed OLM on minikube using two different approaches (both with the same result):

• Follow the install instructions from the release, using install.sh
• Installed as an add on to minikube: minikube addons enable olm

What did you expect to see?
Operators listed when I run k get packagemanifest -A

What did you see instead? Under which circumstances?
It says "No resources found". I was under the impression that the default catalog source that gets created on installation would pull in operators from operatorhub.io. The spec for the generated catalog source is:

  spec:
    displayName: Community Operators
    image: quay.io/operator-framework/upstream-community-operators:latest
    publisher: OperatorHub.io
    sourceType: grpc

Environment

• operator-lifecycle-manager version:

quay.io/operator-framework/olm@sha256:0d15ffb5d10a176ef6e831d7865f98d51255ea5b0d16403618c94a004d049373

• Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T14:23:04Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind:

minikube version: v1.13.0
commit: 0c5e9de4ca6f9c55147ae7f90af97eff5befef5f-dirty

Possible Solution

Additional context
The logs on the catalog operator repeat the text:

time="2020-10-06T15:28:24Z" level=info msg="state.Key.Namespace=olm state.Key.Name=operatorhubio-catalog state.State=CONNECTING"
time="2020-10-06T15:28:25Z" level=info msg="state.Key.Namespace=olm state.Key.Name=operatorhubio-catalog state.State=TRANSIENT_FAILURE"

[benluddy]

I can reproduce this. The catalog pod is crashlooping on OOM, but I don't know what is choosing these limits (the catalog operator only sets resource requests):

    resources:
      limits:
        cpu: 100m
        memory: 100Mi
      requests:
        cpu: 10m
        memory: 50Mi

[benluddy]

On closer inspection... the minikube olm addon is using a fairly old digest. There were resource limits on catalog pods created at that time:

operator-lifecycle-manager/pkg/controller/registry/reconciler/reconciler.go

Lines 130 to 139 in 12c06cf

	Resources: v1.ResourceRequirements{
	Limits: v1.ResourceList{
	v1.ResourceCPU: resource.MustParse("100m"),
	v1.ResourceMemory: resource.MustParse("100Mi"),
	},
	Requests: v1.ResourceList{
	v1.ResourceCPU: resource.MustParse("10m"),
	v1.ResourceMemory: resource.MustParse("50Mi"),
	},
	},

.

[burrsutter]

looks like the workaround is
curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.16.1/install.sh | bash -s 0.16.1

[stale]

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.

[awgreene]

The OLM team is not responsible for maintaining the minikube addons command.

We had attempt to update the manifests used in this command to a newer version, but broke minikube's e2e tests:

• The minikube e2e tests rely on kubectl apply
• kubectl apply has a bug that causes timeouts on large yaml files
• OLM's CRDs are quite large and hit the kubectl apply but, breaking minikube's e2e test

Please submit a bug against the minikube repository.