Annotate CRDs that are installed alongside CSVs.

[benluddy]

In the absence of a way to correlate installed resources back to their
bundle of origin, it's possible for upgrades to complete
early. Upgrades begin when the catalog operator creates a new
CSV (with .spec.replaces set) as part of InstallPlan execution, and
complete when the olm operator sees that the new CSV has .status.phase
Succeeded. When both versions of the operator being upgraded own the
same CRD, the new CSV may use the existing CRD to satisfy its CRD
ownership requirement, thereby transitioning to Succeeded and deleting
the old CSV.

This problem can be avoided for namespace-scoped bundle resources,
which perform the transfer by adding the new CSV as an owner reference
and allowing garbage collection to remove the old owner reference
post-upgrade. This is not possible for CRDs because cluster-scoped
resources cannot have owner references to a namespace-scoped resource
like ClusterServiceVersion.

It may be necessary to make a similar change affecting other
cluster-scoped resources, but CRDs are a common culprit of early
upgrade completion. Ideally, a first-class, cluster-scoped Bundle
resource will obsolete the need to use an annotation to track bundle
of origin.

Upstream fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1947946

[openshift-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: benluddy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [benluddy]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[exdx]

Just to add more context to the original description:

The problem of early success of the new CSV (based off the ownership of the same CRDs as the old CSV already on-cluster) is that the old CSV gets deleted too early. The old CSV may have ownerrefs to different resources which would then be GC'd automatically and cause the new CSV to go into a pending state. For example, if the old CSV owned a ServiceAccount, it would be removed before the new CSV could use it, and the new CSV would then be stuck in a Pending phase.

Early success of the new CSV can also have an impact in the case where CR validation fails, but the CSV is in a succeeded state (since the CRDs it needs are already on-cluster), which the user may not notice unless they check the InstallPlan.

[njhale]

Nice job!

I think this is really close.

[njhale]

nit: is this supposed to be part of the following group of imports?

[benluddy]

/hold

[benluddy]

/hold cancel

[njhale]

/lgtm