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

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

• Change LVMS APIs to be compliant to the official Kubernetes API Conventions
• Change LVMS APIs to be compliant to KEP-1623: Standardize Conditions
• Change LVMS APIs to be compliant with Cluster/Namespaced Operator-Scope definitions

Why is this important?

• API Conventions should be upheld to allow for future upgradeability, ease of adoption when using LVMS and not running into any surprises when interacting with the LVMS APIs. Ultimately "The conventions of the Kubernetes API (and related APIs in the ecosystem) are intended to ease client development and ensure that configuration mechanisms can be implemented that work across a diverse set of use cases consistently."
• KEP-1623 should be upheld because many Kubernetes APIs have .status.conditions but the schema of condition varies a lot between them. There is very little commonality at the level of serialization, proto-encoding, and required vs optional. Conditions are central enough to the API to make a common golang type with a fixed schema. The schema can be a strong recommendation to all API authors. Ultimately this will allow us to leverage that standard and introduce more transparency into our Status
• Operator scope should be upheld because a namespace-scoped operator watches and manages resources in a single Namespace, whereas a cluster-scoped operator watches and manages resources cluster-wide. An operator should be cluster-scoped if it watches resources that can be created in any Namespace. An operator should be namespace-scoped if it is intended to be flexibly deployed. This scope permits decoupled upgrades, namespace isolation for failures and monitoring, and differing API definitions. We do not use cluster-scope for almost all of our resources but "openshift-storage", only very few resources are required at cluster level. We should evaluate which resources can be dropped from cluster-scope and if we can reduce RBAC permissions for most of our resources to namespaced resources.

Scenarios

1. Create and Use LVMS in any configuration that requires interaction with the API (all scenarios that use LVMS APIs are impacted)

Acceptance Criteria

• Acceptance of one or many Enhancement Proposals detailing the changes to the APIs
• Successful Creation of a new API Version with a defined migration and deprecation Path from the old API Version
• Documentation of mentioned migration and deprecation Path
• Adoption of migrated APIs
• Eventual EOL of the old APIs and introduction of follow-up Epics for phasing out

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. Evaluation of API Mechanics in LVMS and spikes for evaluation of effort and preparation of the Enhancement Proposal

Open questions::

1. How to rollout / phaseout new API Versions within Openshift Optional Operators Lifecycle. Any defined Versions?
2. Will we need to define Conversion Webhooks or are we okay with breaking because we are still running in v1alpha1.

Done Checklist

• DOC - Downstream documentation merged: https://github.com/openshift/lvm-operator/pull/432