docs: add design docs for including additional objects in bundles

[exdx]

Description of the change:
Docs for including new objects in the bundle.

• PodDisruptionBudget (policy/v1beta1)
• PriorityClass (scheduling.k8s.io/v1alpha,v1beta1,v1)
• VerticalPodAutoScaler

Docs were written in a generic way to target both upstream and downstream OpenShift audiences. The underlying assumption is that we will allow users to include these objects in the bundle with no limitations on the actual content of these objects.

Motivation for the change:

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Docs updated or added to /docs
• Commit messages sensible and descriptive

[njhale]

These are great notes!

In addition to this, for design proposals we want some more concrete implementation details like:

• How will the new resources be stored in a bundle
• How will they be unpacked and applied to the cluster
• How do we handle incompatibilities; e.g. old version of OLM doesn't know how to apply the new resources, what happens? (think index backport safety)

There are several older examples in the design-proposals directory that may help.

[awgreene]

Great work @exdx! Left a few open questions / brainstorming comments.

Addressed

[exdx]

As this is doc-only we should be OK to merge without CI pending approval.

[kevinrizza]

/approve

[njhale]

So here's an edge case that I think we should cover:

1. I install an operator with a globalDefault=true PDB
2. An update is pushed that changes the name of the PDB
3. Boom?

[exdx]

If I understand this correctly, I think we should be ok in this case - per If you delete a PriorityClass, existing Pods that use the name of the deleted PriorityClass remain unchanged, but you cannot create more Pods that use the name of the deleted PriorityClass. so the rename would't affect existing pods.

see https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#notes-about-podpriority-and-existing-clusters

If the operator continues to use the name of the old PDB in their code then that's an issue, but on their end

[njhale]

If the PDB is renamed in an update, the existing PDB sticks around until the CSV is deleted, which only happens once the new CSV is ready. I think we still would have a problem since there would be a time where you have two PDBs with the global field set true concurrently.

[exdx]

Yes, this is an edge-case that could get us during upgrades of operators with PDBs. I think as we think through the usecases we add e2e tests that can verify OLM behavior in this scenario.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: exdx, kevinrizza

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 [kevinrizza]

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

[ecordell]

/lgtm

[exdx]

manually merging as this is doc-only.