Merge pull request #51547 from smunje1/RHDEVDOCS-4543

RHDEVDOCS-4543 : Disable OLM Descriptor Feature

Author: JStickler

applications/connecting_applications_to_services/exposing-binding-data-from-a-service.adoc

@@ -21,6 +21,7 @@ include::modules/sbo-categories-of-exposable-binding-data.adoc[leveloffset=+1]
 [role="_additional-resources"]
 [id="additional-resources_exposing-binding-data"]
 == Additional resources
-* link:https://github.com/openshift/console/blob/master/frontend/packages/operator-lifecycle-manager/src/components/descriptors/reference/reference.md[OLM Descriptor Reference].
+// * link:https://github.com/openshift/console/blob/master/frontend/packages/operator-lifecycle-manager/src/components/descriptors/reference/reference.md[OLM Descriptor Reference].
+// When OLM descriptors are supported again, add this additional resource.
 * xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-generating-csvs[Defining cluster service versions (CSVs)].
 * xref:../../applications/connecting_applications_to_services/projecting-binding-data.adoc#projecting-binding-data[Projecting binding data].

modules/sbo-categories-of-exposable-binding-data.adoc

@@ -73,6 +73,7 @@ data:
   user: "Z3Vlc3Q="
 ----
 
+////
 The following example shows how to expose an entire config map through OLM descriptors:
 
 .Example: Exposing an entire config map through OLM descriptors
@@ -87,6 +88,8 @@ The following example shows how to expose an entire config map through OLM descr
 This example uses the `path` attribute with a `urn:alm:descriptor:io.kubernetes:ConfigMap` entry to indicate that the path points to the `ConfigMap` service resource.
 
 If you intend to project all the values from a `ConfigMap` service resource, you must specify it as an attribute in the backing service CR. For example, if the attribute is part of the `.spec` section, you can create and use a `specDescriptors` array. Or, if the attribute is part of the `.status` section, you can create and use a `statusDescriptors` array.
+////
+// When the OLM descriptors are supported again, add this example.
 
 [id="exposing-a-specific-entry-from-a-config-map-or-secret-that-is-referenced-from-a-resource_{context}"]
 == Exposing a specific entry from a config map or secret that is referenced from a resource
@@ -117,6 +120,7 @@ data:
   user: "hippo"
 ----
 
+////
 The following example shows how to expose a specific entry from a config map through OLM descriptors:
 
 .Example: Exposing an entry from a config map through OLM descriptors
@@ -132,6 +136,8 @@ This example uses the `path` attribute with an `X-Descriptors` update for `servi
 
 * Name of the binding key that is to be projected
 * Name of the key in the Secret service resource
+////
+// When the OLM descriptors are supported again, add this example.
 
 [id="exposing-a-resource-definition-value_{context}"]
 == Exposing a resource definition value
@@ -150,6 +156,7 @@ metadata:
     ...
 ----
 
+////
 The following example shows how to expose a resource definition value through OLM descriptors:
 
 .Example: Exposing a resource definition value through OLM descriptors
@@ -163,6 +170,8 @@ The following example shows how to expose a resource definition value through OL
 The previous example uses the `connectionURL` attribute that points to the required resource definition value that is to be projected as `uri`.
 
 If required values are available as attributes of backing service resources, annotating these values using `X-Descriptors` identifies them as the binding data.
+////
+// When the OLM descriptors are supported again, add this example.
 
 [id="exposing-entries-of-a-collection-with-the-key-and-value-from-each-entry_{context}"]
 == Exposing entries of a collection with the key and value from each entry
@@ -200,6 +209,7 @@ The following example shows how the previous entries of a collection in annotati
 /bindings/<binding-name>/uri_404 => black-hole.example.com
 ----
 
+////
 The following example shows how to expose the entries of a collection with the key and value from each entry through OLM descriptors:
 
 .Example: Exposing the entries of a collection through OLM descriptors
@@ -211,6 +221,8 @@ The following example shows how to expose the entries of a collection with the k
 ----
 
 The previous example uses the `path` attribute with an `X-Descriptors` update for the required entries of a collection.
+////
+// When the OLM descriptors are supported again, add this example.
 
 .Example: Configuration from a backing service resource
 [source,yaml]
@@ -259,6 +271,7 @@ The following example shows how the previous items of a collection in annotation
 /bindings/<binding-name>/tags_2 => power
 ----
 
+////
 The following example shows how to expose the items of a collection with one key per item through OLM descriptors:
 
 .Example: Exposing the items of a collection through OLM descriptors
@@ -270,6 +283,8 @@ The following example shows how to expose the items of a collection with one key
 ----
 
 The previous example uses the `path` attribute with an `X-Descriptors` update for the required items of a collection.
+////
+// When the OLM descriptors are supported again, add this example.
 
 .Example: Configuration from a backing service resource
 [source,yaml]
@@ -315,6 +330,7 @@ The following example shows how the previous values of a collection in annotatio
 /bindings/<binding-name>/url_2 => black-hole.example.com
 ----
 
+////
 The following example shows how to expose the values of collection entries with one key per entry value through OLM descriptors:
 
 .Example: Exposing the values of collection entries through OLM descriptors
@@ -323,4 +339,6 @@ The following example shows how to expose the values of collection entries with
 - path: bootstrap
   x-descriptors:
   - service.binding:endpoints:elementType=sliceOfStrings:sourceValue=url
-----
+----
+////
+// When the OLM descriptors are supported again, add this example.

modules/sbo-data-model.adoc

@@ -7,7 +7,10 @@
 = Data model
 
 [role="_abstract"]
-The data model used in the annotations and OLM descriptors follow specific conventions.
+// The data model used in the annotations and OLM descriptors follow specific conventions.
+// When the OLM descriptors are supported again, add this sentence.
+
+The data model used in the annotations follows specific conventions.
 
 Service binding annotations must use the following convention:
 
@@ -21,7 +24,8 @@ where:
 `<NAME>`:: Specifies the name under which the binding value is to be exposed. You can exclude it only when the `objectType` parameter is set to `Secret` or `ConfigMap`.
 `<VALUE>`:: Specifies the constant value exposed when no `path` is set.
 
-Although, the data model is the same for custom resource definitions (CRD), custom resource (CR) annotations, and Operator Lifecycle Manager (OLM) descriptors, the syntax for each one differs.
+// Although, the data model is the same for custom resource definitions (CRD), custom resource (CR) annotations, and Operator Lifecycle Manager (OLM) descriptors, the syntax for each one differs.
+// When the OLM descriptors are supported again, add this sentence.
 
 The data model provides the details on the allowed values and semantic for the `path`, `elementType`, `objectType`, `sourceKey`, and `sourceValue` parameters.
 

modules/sbo-key-features.adoc

@@ -8,7 +8,8 @@
 
 * Exposal of binding data from services
 ** Based on annotations present in CRD, custom resources (CRs), or resources.
-** Based on descriptors present in Operator Lifecycle Manager (OLM) descriptors.
+// ** Based on descriptors present in Operator Lifecycle Manager (OLM) descriptors.
+// When the OLM descriptors are supported again, add this sentence.
 * Workload projection
 ** Projection of binding data as files, with volume mounts.
 ** Projection of binding data as environment variables.

modules/sbo-methods-of-exposing-binding-data.adoc

@@ -23,7 +23,8 @@ You must expose the binding data from the backing service. Depending on your wor
 +
 ** Direct secret reference
 ** Declaring binding data through custom resource definition (CRD) or CR annotations
-** Declaring binding data through Operator Lifecycle Manager (OLM) descriptors
+// ** Declaring binding data through Operator Lifecycle Manager (OLM) descriptors
+// When the OLM descriptors are supported again, add this sentence.
 ** Detection of binding data through owned resources
 
 [id="provisioned-service_{context}"]
@@ -199,6 +200,7 @@ data:
   user: "hippo"
 ----
 
+////
 [id="declaring-binding-data-through-olm-descriptors_{context}"]
 == Declaring binding data through OLM descriptors
 You can use this method if your backing service is provided by an Operator. If your Operator is distributed as an OLM bundle, you can add OLM descriptors to describe the binding data that is to be exposed. The OLM descriptors are part of Cluster Service Version resources. The {servicebinding-title} detects the OLM descriptors and then creates a `Secret` resource with the values extracted based on the detected OLM descriptors.
@@ -235,6 +237,8 @@ The following examples show how to define an X-Descriptor depending on the resou
 * You must have a `service.binding` entry in the X-Descriptors to identify that it is a configuration for service binding.
 * The absence of the `Secret` or `ConfigMap` specific X-Descriptors indicates that the descriptor is referencing the binding data value at the given path.
 ====
+////
+// When the OLM descriptors are supported again, add this section.
 
 [id="detection-of-binding-data-through-owned-resources_{context}"]
 == Detection of binding data through owned resources

modules/sbo-naming-strategies.adoc

@@ -21,7 +21,10 @@ While using naming strategies, depending on the expectations or requirements of
 * `title`: Converts the character strings where the first letter of each word is capitalized except for certain minor words.
 
 .Predefined naming strategies
-Binding names declared through annotations or Operator Lifecycle Manager (OLM) descriptors are processed for their name change before their projection into the workload according to the following predefined naming strategies:
+// Binding names declared through annotations or Operator Lifecycle Manager (OLM) descriptors are processed for their name change before their projection into the workload according to the following predefined naming strategies:
+// When the OLM descriptors are supported again, add this sentence.
+
+Binding names declared through annotations are processed for their name change before their projection into the workload according to the following predefined naming strategies:
 
 * `none`: When applied, there are no changes in the binding names.
 +