OCP/Telco Definition of Done
Epic Template descriptions and documentation.

Epic Goal

• Deprecate the `ClusterExtension.spec.serviceAccount` field, make it optional in the API, and stop using it to scope the permissions that OLMv1 uses when lifecycling the ClusterExtension.

Why is this important?

• Since 4.18, OLMv1 has required cluster administrators to provide a service account with each ClusterExtension, which OLMv1 uses to manage the lifecycle of the ClusterExtension. If the ServiceAccount lacks the necessary permissions, OLMv1 experiences permission failures at the time that a missing permission is needed.

The original intent of the feature was to provide a more secure system (OLMv1 itself has fewer direct permissions) and to be used as a policy mechanism to restrict ClusterExtensions from gaining new permissions automatically through updates.

However, there are a few problems with the mechanics of the feature:

1. 1. The UX of creating a ServiceAccount with the necessary permissions is very difficult because the necessary permissions are only knowable once a bundle has been resolved and any user-provided configuration has been applied.
   2. Users who have create permission on ClusterExtensions can create a ClusterExtension in a namespace that already contains a cluster-admin bound service account. This fact means that the ClusterExtension API can't be delegated to non-cluster admins in its current form.
   3. OLMv1 itself needs to use the user-provided service account for somewhat internal purposes. For example, OLMv1's current implementation uses informers to provide an event stream for changes to OLMv1-managed operator manifests. This implementation detail leaks into user-required configuration, which causes fragility and complexity if/when OLM internal implementation details that require the service account change.

Scenarios

1. ...

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• A new ClusterExtension can be created without providing `spec.serviceAccount`.
• An existing ClusterExtension can be updated with a removal of the `spec.serviceAccount` field.
• If `spec.serviceAccount` is provided, it must still include a valid `spec.serviceAccount.name`.
• If a `spec.serviceAccount` is provided, OLMv1 ignores it.
• OLMv1's service account is granted cluster-admin.
• OLMv1 uses its service account for all interactions with the cluster's apiserver.
• Code related to the feature-gated permissions preflight check is removed.

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. Other than permissions bound to the service account, does OLM use anything else associated with it (e.g. service account secrets and imagePullSecrets)? If so, do we need to provide an alternative mechanism for users to provide these things to OLMv1?
2. Is it possible to actually remove the field without breaking existing clients?
   1. If a client sends a request that includes setting that field, will the request still succeed (and drop the spec.serviceAccount as a unknown field)?
   2. If a client using an old API definition deserializes a ClusterExtension that does not set `spec.serviceAccount` will the deserialization succeed? 
      1. If the deserialization succeeds do we expect existing clients to handle a missing service account?
   3. If so (or if we deem this issues unimportant), should we go ahead and remove the field

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>

Scope of work

1. spike to orient
   1. learn the domain and determine what follow-on work is needed to complete, ask the big questions, etc.
2.  implementation code/test
   1. code changes
   2. unit tests updates (due to removal)
   3. e2e tests updates ("")
   4. new upgrade test scenarios as needed to ensure the change is non-breaking (w.r.t. crd upgrade safety, a one-step field removal, etc.)
3. enhancement proposal to cover the change
   1. open enhancement proposal in openshift/enhancements describing intent; get reviews and merge it