-
Epic
-
Resolution: Done
-
Major
-
openshift-4.14
-
Bootstrap simple Operator API and Controller
-
Upstream
-
9
-
False
-
None
-
False
-
Not Selected
-
To Do
-
OCPSTRAT-199 - [Phase 1 MVP/Tech Preview] OLM 1.0 - Cluster-level Operator API (B1)
-
Impediment
-
OCPSTRAT-199[Phase 1 MVP/Tech Preview] OLM 1.0 - Cluster-level Operator API (B1)
-
0% To Do, 0% In Progress, 100% Done
Epic Goal
- The goal of this epic is to introduce a limited version the Operator API that enables users to specify a package that they would like to install on the cluster.
Why is this important?
- The Operator API will act as a top-level resource for users installing operators. This viewpoint will significantly improve the users ability to understand the state of a given operator.
- The proposed API introduced in this epic consists of a single field within the spec. This is the minimum API service that enables developers to introduce a workflow that will install an operator from a catalogSource on cluster. This work will eventually be expanded upon so we may realize the goals of OLM v1.
Scenarios
- As a cluster administrator, I would like to install the cockroachdb operator.
- As a cluster administrator, I would like to install the prometheus operator.
- As a cluster administrator, I would like to know what error is preventing me from installing an operator.
- A simple e2e test is introduced that ensures that the controller is successfully reconciling Operator CRs created on cluster.
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- tflannag@redhat.com's existing work in the main branch is moved to a new prototype branch.
- A new project is created with Kubebuilder.
- A new operator CRD is created.
- A controller exists that reconciles the operator CR.
Dependencies (internal and external)
- N/A
Previous Work (Optional):
- tflannag@redhat.com took an initial swing at prototyping the operator API, which can be seen here. Some of the design decisions made in this branch do not align with the current goals of the team, and so the work will be stored in a historical branch named `prototype`
Upstream Issue:
Open questions:
- N/A
Done Checklist
- CI - CI is running, tests are automated and merged.
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>