-
Feature
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
Feature Overview (aka. Goal Summary)
OLM 1.0 makes it easier to package an existing upstream Operator project in a plain bundle format which can be installed and updated via OLM with little to no degradation in experience compared to packaging as a CSV delivered in FBC.
Goals (aka. expected user outcomes)
- Operator developers can easily package an existing upstream Operator project with k8s manifests as an Operator managed by the OLM 1.0 without composing the CSV objects.
- Operator developers can include any arbitrary “kubectl-able” resource manifests in their bundle and expect OLM to apply and manage it.
- Operator developers can ship general package level info and/or customized UI features in metadata for display and discoverability without the CSV objects.
Requirements (aka. Acceptance Criteria):
| Requirement | Notes | isMvp? |
| (bundle metadata) Define a set of “immutable (and mandatory) metadata” for a bundle version that does not require packaging a CSV but just with plain/regular Kubernetes manifests so it can be installed and updated via OLM 1.0. | YES | |
| (catalog metadata) Separate “immutable metadata” out from the bundle and store them as another distinct form (potentially bundle-format agnostic + seek upstream consensus if possible). | YES | |
| (bundle/catalog metadata) Define metadata that covers “general package level info” in UIs (e.g., OpenShift console/OperatorHub), which is currently stored in CSV’s metadata and spec fields (see Table 1 and Table 2, seek upstream consensus if possible). | YES | |
| (bundle/catalog metadata) Define metadata that covers use cases to enable features or highlight capabilities in the OpenShift console, which is currently stored in CSV’s metadata.annotations field (see Table 3). | YES | |
| (catalog metadata) define additional metadata specific to a release of the operator (e.g., Release Notes) | YES | |
| (arbitrary Kubernetes manifests) A user can ship a set of well-known k8s manifests that OLM will manage with custom semantics (e.g., a namespace manifest gets deployed first as the installation namespace) | YES | |
| (arbitrary Kubernetes manifests) A user can specify additional arbitrary Kubernetes manifests to be considered as a part of the Operator installation | YES | |
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. | YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. | YES |
Use Cases (Optional):
Main use case:
- Operator authors can package a version of Operator in plain k8s manifests with a set of immutable (mandatory) metadata as a bundle which can be installed and updated via OLM 1.0.
- Operator authors can package a series of bundle versions as an Operator package with a set of metadata for OLM 1.0 that either covers “general package level info” or enables features in UIs (e.g., OpenShift console/OperatorHub) without storing metadata in the CSV object as OLM 0.x (see Table 1 and Table 2 and Table 3).
- Operator authors can specify release specific information (e.g., release notes) with a defined metadata for an Operator package.
- Operator authors can ship a set of well-known k8s manifests that OLM will manage with custom semantics (e.g., a namespace manifest gets deployed first as the installation namespace).
- Operator authors can include arbitrary Kubernetes manifests to be considered as a part of the Operator installation.
Questions to Answer (Optional):
Include a list of refinement / architectural questions that may need to be answered before coding can begin. Initial completion during Refinement status.
Out of Scope
High-level list of items that are out of scope. Initial completion during Refinement status.
Background
Provide any additional context is needed to frame the feature. Initial completion during Refinement status.
Customer Considerations
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature. Initial completion during Refinement status.
Documentation Considerations
Provide information that needs to be considered and planned so that documentation will meet customer needs. Initial completion during Refinement status.
Interoperability Considerations
Which other projects and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.
