CSV owned deployment does not controller true reference

[esara]

Bug Report

What did you do?
I am deploying operators from an operator catalog using OLM (in openshift or upsteam)

What did you expect to see?
I see the operator deployment created and it is owned/controlled by the CSV, specifically the "controller: true" attribute under ownerReferences

What did you see instead? Under which circumstances?
but the controller is false (it does not matter which csv/operator I am using - this is just an example)

$ oc get csv -n openshift-operators
NAME DISPLAY VERSION REPLACES PHASE
redhat-openshift-pipelines.v1.5.2 Red Hat OpenShift Pipelines 1.5.2 redhat-openshift-pipelines.v1.4.1 Succeeded

$ oc get deployment -n openshift-operators openshift-pipelines-operator -o=jsonpath='{.metadata.ownerReferences[]}'
{"apiVersion":"operators.coreos.com/v1alpha1","blockOwnerDeletion":false,"controller":false,"kind":"ClusterServiceVersion","name":"redhat-openshift-pipelines.v1.5.2","uid":"c7071a78-4dd6-45d7-8cc1-9cb80dfae4dd"}

Environment

• operator-lifecycle-manager version:
  https://github.com/operator-framework/operator-lifecycle-manager/releases/tag/v0.20.0
  same behaviour in OCP 4.8

• Kubernetes version information:
  $ kubectl version
  Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.6+bb8d50a", GitCommit:"cefce093e4e5bc9a1916eb5a489ed37c7d467f6f", GitTreeState:"clean", BuildDate:"2021-12-21T06:22:19Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind:
  $ oc version
  Server Version: 4.8.26
  Kubernetes Version: v1.21.6+bb8d50a

Possible Solution
can we use true when setting in the ownerreference for CSV created resources?

operator-lifecycle-manager/pkg/lib/ownerutil/util.go

Line 203 in fddbf04

Controller: &NotController,

operator-lifecycle-manager/pkg/lib/ownerutil/util.go

Line 29 in fddbf04

NotController = false

[dinhxuanvu]

I would like to ask why you would like to set this Controller attribute to True. Does the change impact the behavior of the deployment in some way that you expect it to be? I simply want to see your particular use case for the usage of that attribute.

[esara]

hi @dinhxuanvu semantically, there should be a significance to this attribute, you can have multiple ownerreferences, but if any of the owner reference is a controller, that is an indication that this deployment should not be modified, because the owner that is the controller is going to reconsile it.
Which is exactly the case here, the OLM will reconsile any changes to this deployment from the CSV, which is not only the owner, but based on this should be the controller for this deployment.
This should inform any automation not to make changes the deployment, but make changes to the controller/owner (the csv) in this case, through any CICD pipeline, so that the changes are correctly applied.

For example, in our code, we rely on this attribute to make (or prevent) changes
https://github.com/turbonomic/kubeturbo/blob/master/pkg/action/executor/k8s_controller.go#L104

And we cater to mapping to the owner in https://github.com/turbonomic/orm/

Please let me know if you need more details...

[kevinwangcn]

I also noticed this on a OCP4.7 cluster. It seems to me the OLM framework intentionally set this controller attribute to false, don't know if there is any special reason for this. but as the ClusterServiceVersion is only owner for a deployment and also it is contorlling the resources request/limit of that deployment, the field is supposed to set true which also fits the fact.