F28 - Provided service versions (aka 'Operand versioning')

Signed-off-by: Tony Wu <tlwu2013@gmail.comexport>

docs/olmv1_roadmap.md

@@ -8,13 +8,13 @@ OLM has unique support for the specific needs of cluster extensions, which are c
 
 OLM defines a lifecycle for these extensions in which they get installed, potentially causing other extensions to be installed as well, a limited set of customization of configuration at runtime, an update model following a path defined by the extension developer, and eventual decommission and removal.
 
-There is a dependency model in which extensions can rely on each other for required services that are out of scope of the primary purpose of the extension, allowing each extension to focus on a specific purpose. OLM also prevents conflicting extensions from running on the cluster, either with conflicting dependency constraints or conflicts in ownership of services provided via APIs.
+There is a dependency model in which extensions can rely on each other for required services (such as Apache Kafka) in a specific version when needed that are out of scope of the primary purpose of the extension, allowing each extension to focus on a specific purpose. OLM also prevents conflicting extensions from running on the cluster, either with conflicting dependency constraints or conflicts in ownership of services provided via APIs.
 
 Since cluster extensions need to be supported with an enterprise-grade product lifecycle the specific scenarios in which an extension can be installed or updated are going to be limited by the author of the extension, primarily to align with what was tested by their QE processes. OLM allows the author to enforce these support  limitations in the form of additional constraints.
 
 During their lifecycle on the cluster, OLM also manages the permissions and capabilities extensions have on the cluster as well as the permission and access tenants on the cluster have to the extensions. This is done using the Kubernetes RBAC system in combination with tenant isolation using Kubernetes namespaces. The interaction surface of the extensions is solely composed of Kubernetes APIs the extensions define.
 
-OLM also defines a packaging model in which catalogs of extensions, usually containing the entire version history of each extension, are made available to clusters for cluster users to browse and select from. Via new versions of extensions delivered with this packaging system, OLM is able to apply updates to existing running extensions on the cluster in a way where the integrity of the cluster is maintained and constraints and dependencies are kept satisfied.
+OLM also defines a packaging model in which catalogs of extensions, usually containing the entire version history of each extension, are made available to clusters for cluster users to browse and select from. As extensions can only be installed once in a cluster as cluster-wide singletons, it is likely for an extension to oversee multiple versions of service and utilize a distinct versioning scheme. To enable cluster users to make informed decisions about which extension version to install or update, a distinct field serves the purpose of specifying a list of service versions (e.g. Apache Kafka) managed by the extension. This field accommodates extensions that provide multiple services (e.g. both Quay and Clair) as well, ensuring comprehensive coverage of all provided services. Via new versions of extensions delivered with this packaging system, OLM is able to apply updates to existing running extensions on the cluster in a way where the integrity of the cluster is maintained and constraints and dependencies are kept satisfied.
 
 The scope of all these features is a single cluster so far with namespace-based handling of catalog access and extension API accessibility and discoverability. Expansion of this scope is indirectly expected through the work of the Kubernetes Control Plane (kcp) project, which in its first incarnation will likely use its own synchronization mechanism to get OLM-managed extensions deployed eventually on one or more physical clusters from a shared, virtual control plane called a “workspace”. This is an area under active development and subject to change, OLM might need to become aware of kcp in a future state.
 
@@ -77,6 +77,8 @@ _Priority Rating: 1 highest, 2 medium, 3 lower (e.g. P2 = Medium Priority)_
 
 **F27 - Pluggable certificate management (P2):** OLM should rely on other controllers to create and lifecycle TLS certificates required to drive the functionality of certain extensions, like webhooks that need to trust /  need to be trusted by the cluster's API server. OLM should not implement any certificate handling itself. In a first implementation support should be established for cert-manager.
 
+**F28 - Provided service versions (P2):** Extensions can offer multiple services with specific version ranges. To help cluster users make informed decisions about which extension version to install or update, OLM should provide a separate field for extension developers to specify the provided services and their respective versions. This will allow for declaring extension dependencies as an additional constraint on specific service versions and enable flexibility in releasing extensions and their corresponding services at different cadences. In disconnected environments, cluster users should be able to deselect provided services and versions during image mirroring.
+
 # Behavioral Requirements
 
 _Priority Rating: 1 highest, 2 medium, 3 lower (ex. P2 = Medium Priority)_