Failed to run `make bundle with v1.18.0

[Madhu-1]

Bug Report

What did you do?

Running make bundle on the project with the latest operator SDK is failing

What did you expect to see?

After updating the operator SDK version the existing make bundle should not be breaking

• We have update the labels on the all the yaml files in our project
• Update operator-sdk from 1.17.0 to 1.18.0 and make bundle is failing

[🎩︎]mrajanna@fedora kubernetes-csi-addons $]make bundle
sed 's/@PACKAGE_NAME@/csi-addons/g' < config/manifests/bases/clusterserviceversion.yaml.in > config/manifests/bases/csi-addons.clusterserviceversion.yaml
go build -o /home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/controller-gen ./vendor/sigs.k8s.io/controller-tools/cmd/controller-gen
go build -o /home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/kustomize ./vendor/sigs.k8s.io/kustomize/kustomize/v4
/home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/controller-gen rbac:roleName=manager-role crd webhook paths="{./api/...,./cmd/...,./controllers/...,./sidecar/...}" output:crd:artifacts:config=config/crd/bases
cd config/manager && /home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/kustomize edit set image controller=quay.io/csiaddons/k8s-controller:latest rbac-proxy=gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
/home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/kustomize build config/crd > deploy/controller/crds.yaml
/home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/kustomize build config/rbac > deploy/controller/rbac.yaml
/home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/kustomize build config/manager > deploy/controller/setup-controller.yaml
go build -o /home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/operator-sdk ./vendor/github.com/operator-framework/operator-sdk/cmd/operator-sdk
/home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/kustomize build config/manifests | /home/mrajanna/workspace/src/github.com/csi-addons/kubernetes-csi-addons/bin/operator-sdk generate bundle --manifests --metadata --package=csi-addons 
Generating bundle manifests
FATA[0000] Error generating bundle manifests: could not find manager deployment, should have label control-plane=controller-manager 
make: *** [Makefile:96: bundle] Error 1

What did you see instead? Under which circumstances?

Environment

Operator type: go

Kubernetes cluster type:

$ operator-sdk version v1.18.0

$ go version (if language is Go) go1.17.4

$ kubectl version

Possible Solution

Additional context

[nixpanic]

It seems that the change was introduced with #5567. The labels to detect the manager container are hard-codedL

operator-sdk/internal/cmd/operator-sdk/generate/bundle/bundle.go

Lines 322 to 328 in c9c61b6

	// findManagerEnvironment returns the environment passed to the controller manager container.
	func (c bundleCmd) findManagerEnvironment(col *collector.Manifests) ([]corev1.EnvVar, error) {
	const (
	managerLabel = "control-plane"
	managerLabelValue = "controller-manager"
	managerContainerName = "manager"
	)

In csi-addons/kubernetes-csi-addons#122 we replaced those labels with our own, as to not cause confusion or conflicts with components that use the standard labels.This might not have been the best approach, but it seemed the most practical.

A recommendation or suggested workaround that makes sense from an operator-framework point of view would be much appreciated.

[camilamacedo86]

Hi @ryantking,

Following some questions, in order to be able to check this one. I hope that can help out.

Why do we need to use the labels to get the manifests? The logic to ensure that all will be mapped via RELATED_IMAGE should not be valid for all images used? Are we not doing the same for the kube-rbac-proxy? If not, why not?

Also, wdyt about creating a sample under testdata dir to scaffold the bundle using this option for we are able to visualize to check its results and be able to easier verify in the review that changes will not affect this feature? (e.g go/v3/digests-operator with an API only) We do not need to call this one in the e2e tests.

c/c @jmrodri

[dvaldivia]

is there a way around this for operators generating bundles using operator-sdk but not created by it?

[acornett21]

I'm interested in a resolution for this as well, as this is a breaking change for all ACK operators.

[pohly]

Hardcoding these labels in operator-sdk seems like a limitation that should be addressed, in particular because the defaults don't follow the recommended naming scheme.

But that aside, which objects should have this label? Looking at the examples under testdata it seems that all (?) have it?

[ryantking]

This is fixed in v1.19.1.