Add support for label selection of Bundles in the BundleDeployment API

[timflannagan]

Goal: mirror the deployment/replicaset pattern and update the BundleDeployment API to have a spec field that contains a label selector to enable pivoting decisions between Bundles that all contain the same label. The underlying provisioner is responsible for making these pivoting decisions.

Example BundleDeployment resource that was outlined in the original e2e strawman:

kind: BundleDeployment
metadata:
  name: etcd-operator
spec:
  selector: 
    matchLabels:
      subscription: etcd-operator

[timflannagan]

Moving this as 0.1 candidate.

[timflannagan]

Moving this as a 0.3 candidate as it's unclear whether this is something we'll need in the short term, or whether we have a concrete use case right now that requires label selection.

[timflannagan]

Just dumping some more context: right now, pivoting between Bundles for an individual BD is a manual process where a user/controller/etc. updates the spec.BundleName field to point to another Bundle's metadata.Name. While this design largely works for the plain provisioner, there may be use cases where automatic pivoting mechanisms are valuable.

This means that using the existing spec.BundleName API design would require a controller to modify the spec fields of the resource it's watching, which seems like a poor implementation the more I think about it. It would be nice instead if we added a label/field selector so a controller responsible for making pivoting decisions only needs to read that value, fire off a list query using that selector, and pivot to a new Bundle resource. That way the controller only needs to propagate state to the Bundle's status sub-resource, vs. modifying the spec field directly.

cc @njhale @joelanford thoughts?

[timflannagan]

Related: #73

[timflannagan]

We're removing this field from the set of changes in #293 as it's not clear we need this top-level field for the time being. Moving this ticket to the backlog.

[github-actions[bot]]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

[github-actions[bot]]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.