Merge pull request #101753 from skopacz1/100838_4.13

[enterprise-4.13] OSDOCS-16572: first batch of rec visibility changes

Author: skopacz1

modules/authentication-authorization-common-terms.adoc

@@ -45,7 +45,12 @@ manual mode::
 In manual mode, a user manages cloud credentials instead of the Cloud Credential Operator (CCO).
 
 mint mode::
-Mint mode is the default and recommended best practice setting for the Cloud Credential Operator (CCO) to use on the platforms for which it is supported. In this mode, the CCO uses the provided administrator-level cloud credential to create new credentials for components in the cluster with only the specific permissions that are required.
+In mint mode, the Cloud Credential Operator (CCO) uses the provided administrator-level cloud credential to create new credentials for components in the cluster with only the specific permissions that are required.
++
+[NOTE]
+====
+Mint mode is the default and the preferred setting for the CCO to use on the platforms for which it is supported.
+====
 
 namespace::
 A namespace isolates specific system resources that are visible to all processes. Inside a namespace, only processes that are members of that namespace can see those resources.

modules/ldap-syncing-nesting.adoc

@@ -129,7 +129,12 @@ values are ignored. `groupsQuery` must set a valid `derefAliases`.
 <2> The attribute that uniquely identifies a group on the LDAP server. It must be set to `dn`.
 <3> The attribute to use as the name of the group.
 <4> The attribute to use as the name of the user in the {product-title} group
-record. `mail` or `sAMAccountName` are preferred choices in most installations.
+record.
++
+[NOTE]
+====
+`mail` or `sAMAccountName` are preferred choices in most installations.
+====
 <5> The attribute on the user that stores the membership information. Note the use
 of https://msdn.microsoft.com/en-us/library/aa746475(v=vs.85).aspx[`LDAP_MATCHING_RULE_IN_CHAIN`].
 

modules/olm-accessing-images-private-registries.adoc

@@ -117,6 +117,7 @@ Repeat this step to create additional secrets for any other required private reg
 
 . Create or update an existing `CatalogSource` object to reference one or more secrets:
 +
+--
 [source,yaml]
 ----
 apiVersion: operators.coreos.com/v1alpha1
@@ -139,7 +140,13 @@ spec:
       interval: 30m
 ----
 <1> Add a `spec.secrets` section and specify any required secrets.
-<2> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
+<2> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`.
++
+[NOTE]
+====
+If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
+====
+--
 
 . If any Operator or Operand images that are referenced by a subscribed Operator require access to a private registry, you can either provide access to all namespaces in the cluster, or individual target tenant namespaces.
 

modules/olm-creating-catalog-from-index.adoc

@@ -67,9 +67,10 @@ ifdef::olm-restricted-networks[]
 If you used the `oc adm catalog mirror` command to mirror your catalog to a target registry, you can use the generated `catalogSource.yaml` file in your manifests directory as a starting point.
 endif::[]
 
+ifdef::olm-restricted-networks[]
 .. Modify the following to your specifications and save it as a `catalogSource.yaml` file:
 +
-ifdef::olm-restricted-networks[]
+--
 [source,yaml,subs="attributes+"]
 ----
 apiVersion: operators.coreos.com/v1alpha1
@@ -90,12 +91,21 @@ spec:
 ----
 <1> If you mirrored content to local files before uploading to a registry, remove any backslash (`/`) characters from the `metadata.name` field to avoid an "invalid resource name" error when you create the object.
 <2> If you want the catalog source to be available globally to users in all namespaces, specify the `{namespace}` namespace. Otherwise, you can specify a different namespace for the catalog to be scoped and available only for that namespace.
-<3> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
+<3> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`.
++
+[NOTE]
+====
+If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
+====
 <4> Specify your index image. If you specify a tag after the image name, for example `:{tag}`, the catalog source pod uses an image pull policy of `Always`, meaning the pod always pulls the image prior to starting the container. If you specify a digest, for example `@sha256:<id>`, the image pull policy is `IfNotPresent`, meaning the pod pulls the image only if it does not already exist on the node.
 <5> Specify your name or an organization name publishing the catalog.
 <6> Catalog sources can automatically check for new versions to keep up to date.
+--
 endif::[]
 ifndef::olm-restricted-networks[]
+.. Modify the following to your specifications and save it as a `catalogSource.yaml` file:
++
+--
 [source,yaml,subs="attributes+"]
 ----
 apiVersion: operators.coreos.com/v1alpha1
@@ -119,10 +129,16 @@ spec:
 ----
 <1> If you want the catalog source to be available globally to users in all namespaces, specify the `{namespace}` namespace. Otherwise, you can specify a different namespace for the catalog to be scoped and available only for that namespace.
 <2> Optional: Set the `olm.catalogImageTemplate` annotation to your index image name and use one or more of the Kubernetes cluster version variables as shown when constructing the template for the image tag.
-<3> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
+<3> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`.
++
+[NOTE]
+====
+If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
+====
 <4> Specify your index image. If you specify a tag after the image name, for example `:{tag}`, the catalog source pod uses an image pull policy of `Always`, meaning the pod always pulls the image prior to starting the container. If you specify a digest, for example `@sha256:<id>`, the image pull policy is `IfNotPresent`, meaning the pod pulls the image only if it does not already exist on the node.
 <5> Specify your name or an organization name publishing the catalog.
 <6> Catalog sources can automatically check for new versions to keep up to date.
+--
 endif::[]
 
 .. Use the file to create the `CatalogSource` object:

modules/olm-dependency-resolution-preferences.adoc

@@ -28,7 +28,12 @@ spec:
   displayName: "My Operators"
   priority: 100
 ----
-<1> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
+<1> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`.
++
+[NOTE]
+====
+If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
+====
 
 A `CatalogSource` object has a `priority` field, which is used by the resolver to know how to prefer options for a dependency.
 

modules/telemetry-consequences-of-disabling-telemetry.adoc

@@ -6,16 +6,19 @@
 [id="telemetry-consequences-of-disabling-telemetry_{context}"]
 = Consequences of disabling remote health reporting
 
-In {product-title}, customers can disable reporting usage information. 
+In {product-title}, customers can disable reporting usage information.
 
 Before you disable remote health reporting, read the following benefits of a connected cluster:
 
 * Red{nbsp}Hat can react more quickly to problems and better support our customers.
-* Red{nbsp}Hat can better understand how product upgrades impact clusters. 
+* Red{nbsp}Hat can better understand how product upgrades impact clusters.
 * Connected clusters help to simplify the subscription and entitlement process.
 * Connected clusters enable the {cluster-manager} service to offer an overview of your clusters and their subscription status.
 
+[NOTE]
+====
 Consider leaving health and usage reporting enabled for pre-production, test, and production clusters. This means that Red{nbsp}Hat can participate in qualifying {product-title} in your environments and react more rapidly to product issues.
+====
 
 The following lists some consequences of disabling remote health reporting on a connected cluster: