InstallPlan is missing expected OwnerReference to Subscription

[JustinKuli]

Bug Report

What did you do?

I created a subscription with installPlanApproval: Manual, and I manually approved the InstallPlan that was created. Then I created another subscription with installPlanApproval: Automatic.

What did you expect to see?

I expected to find a new InstallPlan with an OwnerReference to my new Subscription. And sometimes I do, like this:

> kubectl get installplan -A -oyaml
apiVersion: v1
items:
- apiVersion: operators.coreos.com/v1alpha1
  kind: InstallPlan
  metadata:
    creationTimestamp: "2024-04-04T19:36:01Z"
    generateName: install-
    generation: 2
    labels:
      operators.coreos.com/authorino-operator.operator-policy-testns: ""
    name: install-rz5dg
    namespace: operator-policy-testns
    ownerReferences:
    - apiVersion: operators.coreos.com/v1alpha1
      blockOwnerDeletion: false
      controller: false
      kind: Subscription
      name: authorino-operator
      uid: 47388ade-cf23-44f1-823e-9679e2af7410
    - apiVersion: operators.coreos.com/v1alpha1
      blockOwnerDeletion: false
      controller: false
      kind: Subscription
      name: project-quay
      uid: f9c66ac8-2757-497e-94a8-90b3f9347bf9

What did you see instead? Under which circumstances?

Sometimes (and I don't know what causes this - I'm running this inside a test suite so it's a consistent setup from my perspective) the InstallPlan does not have an OwnerReference for the new subscription, only the old one, like this:

> kubectl get installplan -A -oyaml
apiVersion: v1
items:
- apiVersion: operators.coreos.com/v1alpha1
  kind: InstallPlan
  metadata:
    creationTimestamp: "2024-04-04T19:33:30Z"
    generateName: install-
    generation: 2
    labels:
      operators.coreos.com/authorino-operator.operator-policy-testns: ""
    name: install-9r95l
    namespace: operator-policy-testns
    ownerReferences:
    - apiVersion: operators.coreos.com/v1alpha1
      blockOwnerDeletion: false
      controller: false
      kind: Subscription
      name: project-quay
      uid: 93069a46-a835-487b-90bf-04953b98cb4e
    resourceVersion: "23914"
    uid: 1559fed3-e522-459b-9238-07503e0c55e4

Environment

• operator-lifecycle-manager version: v0.26.0

• Kubernetes version information:

  ❯ kubectl version
  Client Version: v1.29.3
  Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
  Server Version: v1.29.2

• Kubernetes cluster kind: vanilla / Kubernetes-In-Docker kind v0.22.0 running with podman

Possible Solution

I'd still consider it a bug, but a workaround is to use the label to find the InstallPlan, which can be easily determined from the Subscription details.

Additional context

This might be related to https://github.com/operator-framework/operator-lifecycle-manager/issues/3052, but it seemed like that issue might have been confused by there being two OwnerReferences, one for each Subscription... I don't mind that there might be two owners, I just wish one of the owners was the subscription that actually caused the InstallPlan to be created.

[JustinKuli]

Thinking about it more, it would actually be really nice if the only owner of the InstallPlan was the subscription that caused it to be created. The label I found seems to be removed from old install plans, so it can't be used to find old ones in case I'm interested in the history of the operator.