PR for SRVCOM-4313: CQA + DITA readiness for assemblies and modules under the "Integrations" section

integrations/gpu-resources.adoc

@@ -1,18 +1,19 @@
 :_mod-docs-content-type: ASSEMBLY
-include::_attributes/common-attributes.adoc[]
 [id="gpu-resources"]
 = Using NVIDIA GPU resources with serverless applications
+include::_attributes/common-attributes.adoc[]
 :context: gpu-resources
 
 toc::[]
 
 [role="_abstract"]
-NVIDIA supports using GPU resources on {ocp-product-title}.
-See link:https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/openshift/contents.html[GPU Operator on OpenShift] for more information about setting up GPU resources on {ocp-product-title}.
+You can use NVIDIA GPU resources in serverless applications on {ocp-product-title} to accelerate compute-intensive workloads such as machine learning and data processing.
 
 include::modules/serverless-gpu-resources-kn.adoc[leveloffset=+1]
 
-[id="additional-requirements_gpu-resources"]
 [role="_additional-resources"]
-== Additional resources for {ocp-product-title}
+== Additional resources
+
 * link:https://docs.openshift.com/container-platform/latest/applications/quotas/quotas-setting-per-project.html#quotas-setting-per-project[Setting resource quotas for extended resources]
+
+* link:https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/openshift/contents.html[GPU Operator on OpenShift]

integrations/serverless-cost-management-integration.adoc

@@ -1,25 +1,29 @@
 :_mod-docs-content-type: ASSEMBLY
-include::_attributes/common-attributes.adoc[]
 [id="serverless-cost-management-integration"]
-= Integrating {ServerlessProductShortName} with the cost management service
+= Integrating OpenShift Serverless with the cost management service
+include::_attributes/common-attributes.adoc[]
 :context: serverless-cost-management-integration
 
 toc::[]
 
 [role="_abstract"]
-link:https://docs.redhat.com/en/documentation/cost_management_service/1-latest/html/getting_started_with_cost_management/index[Cost management] is an {ocp-product-title} service that enables you to better understand and track costs for clouds and containers. It is based on the open source link:https://project-koku.github.io/[Koku] project.
-
-[id="prerequisites_serverless-cost-management-integration"]
-== Prerequisites
+You can integrate Serverless with the cost management service in {ocp-product-title} to track and analyze costs for cloud and container workloads. The service uses the open source Koku project to offer cost visibility and insights.
 
-* You have cluster administrator permissions.
-
-* You have set up cost management and added an link:https://docs.redhat.com/en/documentation/cost_management_service/1-latest/html/integrating_openshift_container_platform_data_into_cost_management/index[{ocp-product-title} source].
+include::modules/serverless-cost-management-integration-prereqs.adoc[leveloffset=+1]
 
 include::modules/serverless-cost-management-labels.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
-[id="additional-resources_serverless-cost-management-integration"]
 == Additional resources
+
+* link:https://docs.redhat.com/en/documentation/cost_management_service/1-latest/html/getting_started_with_cost_management/index[Cost management]
+
+* link:https://project-koku.github.io/[Koku]
+
+* link:https://docs.redhat.com/en/documentation/cost_management_service/1-latest/html/integrating_openshift_container_platform_data_into_cost_management/index[{ocp-product-title} source]
+
 * link:https://docs.redhat.com/en/documentation/cost_management_service/1-latest/html-single/managing_cost_data_using_tagging/index#why-use-tags_planning-your-tagging-strategy[Managing cost data using tagging]
+
 * link:https://docs.redhat.com/en/documentation/cost_management_service/1-latest/html-single/visualizing_your_costs_using_cost_explorer/index[Visualizing your costs using cost explorer]
+
+* link:https://console.redhat.com/openshift/cost-management/[Red Hat hybrid console]

integrations/serverless-integrating-service-mesh/serverless-ossm-setup.adoc

@@ -11,7 +11,7 @@ The {ServerlessOperatorName} provides Kourier as the default ingress for Knative
 
 Note the following assumptions and limitations:
 
-* All Knative internal components, as well as Knative Services, are part of the {SMProductShortName} and have sidecars injection enabled. This means that strict mTLS is enforced within the whole mesh. All requests to Knative Services require an mTLS connection, with the client having to send its certificate, except calls coming from OpenShift Routing.
+* All Knative internal components, and Knative Services, are part of the {SMProductShortName} and have sidecars injection enabled. This means that strict mTLS is enforced within the whole mesh. All requests to Knative Services require an mTLS connection, with the client having to send its certificate, except calls coming from OpenShift Routing.
 
 * {ServerlessProductName} with {SMProductShortName} integration can only target *one* service mesh. Multiple meshes can be present in the cluster, but {ServerlessProductName} is only available on one of them.
 
@@ -40,7 +40,7 @@ To complete and verify these procedures in your deployment, you need either a ce
 ====
 {ServerlessProductName} only supports the use of {SMProductName} functionality that is explicitly documented in this guide, and does not support other undocumented features.
 
-Using {ServerlessProductShortName} 1.31 with {SMProductShortName} is only supported with {SMProductShortName} version 2.2 or later. For details and information on versions other than 1.31, see the "Red Hat OpenShift Serverless Supported Configurations" page.
+Using {ServerlessProductShortName} 1.31 with {SMProductShortName} is only supported with {SMProductShortName} version 2.2 or later. For details and information about versions other than 1.31, see the "Red Hat OpenShift Serverless Supported Configurations" page.
 ====
 
 include::modules/serverless-ossm-external-certs.adoc[leveloffset=+1]
@@ -58,7 +58,7 @@ include::modules/serverless-ossm-verifying-the-integration.adoc[leveloffset=+2]
 
 include::modules/serverless-ossm-enabling-serving-metrics.adoc[leveloffset=+1]
 include::modules/serverless-ossm-disabling-network-policies.adoc[leveloffset=+1]
-// with kourier
+
 include::modules/serverless-ossm-secret-filtering-net-istio.adoc[leveloffset=+1]
 
 [id="additional-resources_serverless-ossm-setup"]

integrations/serverless-integrating-service-mesh/serverless-ossm-traffic-isolation.adoc

@@ -11,26 +11,19 @@ You can use {SMProductShortName} 2.x with {ServerlessProductName} to control and
 
 :FeatureName: Using {SMProductShortName} to isolate network traffic with {ServerlessProductName}
 include::snippets/technology-preview.adoc[leveloffset=+2]
+:!FeatureName:
 
-{SMProductShortName} can be used to isolate network traffic between tenants on a shared {product-title} cluster using Service Mesh `AuthorizationPolicy` resources. {ServerlessProductShortName} can also leverage this, using several {SMProductShortName} resources. A tenant is a group of one or multiple projects that can access each other over the network on a shared cluster.
-
-[id="prerequisites_serverless-ossm-traffic-isolation"]
-== Prerequisites
-
-* You have access to an {product-title} account with cluster administrator access.
-
-* You have set up the {SMProductShortName} 2.x and {ServerlessProductShortName} integration.
-
-* You have created one or more OpenShift projects for each tenant.
+{SMProductShortName} can be used to isolate network traffic between tenants on a shared {product-title} cluster by using Service Mesh `AuthorizationPolicy` resources. {ServerlessProductShortName} can also use this, using several {SMProductShortName} resources. A tenant is a group of one or multiple projects that can access each other over the network on a shared cluster.
 
 include::modules/serverless-ossm-traffic-isolation-architecture.adoc[leveloffset=+1]
 
 include::modules/serverless-ossm-traffic-isolation-securing-the-service-mesh.adoc[leveloffset=+1]
 
 include::modules/serverless-ossm-traffic-isolation-verifying-the-configuration.adoc[leveloffset=+1]
 
-
 [role="_additional-resources"]
-.Additional resources for {ocp-product-title}
+== Additional resources
+
 * link:https://github.com/openshift-knative/knative-istio-authz-chart[The Helm utility]
+
 * link:https://github.com/openshift-knative/knative-istio-authz-chart/blob/main/values.yaml[Option reference for the Helm utility]

integrations/serverless-pipelines-integration.adoc

@@ -1,27 +1,17 @@
 :_mod-docs-content-type: ASSEMBLY
-include::_attributes/common-attributes.adoc[]
 [id="serverless-pipelines-integration"]
-= Integrating {ServerlessProductShortName} with {pipelines-shortname}
+= Integrating OpenShift Serverless with {pipelines-shortname}
+include::_attributes/common-attributes.adoc[]
 :context: serverless-pipelines-integration
 
 toc::[]
 
 [role="_abstract"]
 Integrating {ServerlessProductShortName} with {pipelines-shortname} enables CI/CD pipeline management for {ServerlessProductShortName} services. Using this integration, you can automate the deployment of your {ServerlessProductShortName} services.
 
-[id="prerequisites_serverless-pipelines-integration"]
-== Prerequisites
-
-* You have access to the cluster with `cluster-admin` privileges.
-
-* The {ServerlessOperatorName} and Knative Serving are installed on the cluster.
-
-* You have installed the {pipelines-shortname} Operator on the cluster.
-
 include::modules/serverless-creating-service-deployed-by-openshift-pipelines.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
-[id="additional-resources_serverless-pipelines-integration"]
 == Additional resources
 
 * link:https://docs.openshift.com/pipelines/latest/about/about-pipelines.html[Documentation for {pipelines-title}]

modules/serverless-cost-management-integration-prereqs.adoc

@@ -0,0 +1,14 @@
+// Module included in the following assemblies:
+//
+// * /serverless/integrations/serverless-cost-management-integration.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="serverless-cost-management-integration-prereqs_{context}"]
+= Prerequisites for integrating OpenShift Serverless with the cost management service
+
+[role="_abstract"]
+You can review the required permissions and ensure that cost management is configured with an {ocp-product-title} source before you proceed.
+
+* You have cluster administrator permissions.
+
+* You have set up cost management and added an on {ocp-product-title} source.

modules/serverless-cost-management-labels.adoc

@@ -7,11 +7,12 @@
 = Labels for cost management queries
 
 [role="_abstract"]
-You can apply labels, also known as `tags` in cost management, to nodes, namespaces, or pods. Each label consists of a key-value pair. Use combinations of labels to generate reports. You can access reports about costs by using the link:https://console.redhat.com/openshift/cost-management/[Red Hat hybrid console].
+You can apply labels, also known as `tags` in cost management, to nodes, namespaces, or pods. Each label consists of a key-value pair. Use combinations of labels to generate reports. You can access reports about costs by using the Red{nbsp}Hat hybrid console.
 
 Nodes pass labels to namespaces, and namespaces pass them to pods. However, labels are not overridden if they already exist on a resource. For example, Knative services have a default `app=<revision_name>` label:
 
-.Example Knative service default label
+You get an output similar to the following example:
+
 [source,yaml]
 ----
 apiVersion: serving.knative.dev/v1

modules/serverless-creating-service-deployed-by-openshift-pipelines.adoc

@@ -7,6 +7,12 @@
 [role="_abstract"]
 Using the {ocp-product-title} web console, you can create a service that the {pipelines-shortname} deploys.
 
+.Prerequisites
+
+* You have access to the cluster with `cluster-admin` privileges.
+* You have installed the {ServerlessOperatorName} and Knative Serving on the cluster.
+* You have installed the {pipelines-shortname} Operator on the cluster.
+
 .Procedure
 
 . In the {ocp-product-title} web console navigate to *+Add* and select the *Import from Git* option.

modules/serverless-gpu-resources-kn.adoc

@@ -7,13 +7,13 @@
 = Specifying GPU requirements for a service
 
 [role="_abstract"]
-After GPU resources are enabled for your {ocp-product-title} cluster, you can specify GPU requirements for a Knative service using the Knative (`kn`) CLI.
+After you enable GPU resources for your {ocp-product-title} cluster, specify GPU requirements for a Knative service by using the Knative (`kn`) CLI.
 
 .Prerequisites
 
-* The {ServerlessOperatorName}, Knative Serving and Knative Eventing are installed on the cluster.
+* You have installed the {ServerlessOperatorName}, Knative Serving and Knative Eventing on the cluster.
 * You have installed the Knative (`kn`) CLI.
-* GPU resources are enabled for your {ocp-product-title} cluster.
+* You have enabled the GPU resources for your {ocp-product-title} cluster.
 * You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in {ocp-product-title}.
 
 [NOTE]
@@ -27,7 +27,7 @@ Using NVIDIA GPU resources is not supported for {ibmzProductName} and {ibmpowerP
 +
 [source,terminal]
 ----
-$ kn service create hello --image <service-image> --limit nvidia.com/gpu=1
+$ kn service create hello --image <service_image> --limit nvidia.com/gpu=1
 ----
 +
 A GPU resource requirement limit of `1` means that the service has 1 GPU resource dedicated. Services do not share GPU resources. Any other services that require GPU resources must wait until the GPU resource is no longer in use.

modules/serverless-ossm-traffic-isolation-architecture.adoc

@@ -1,44 +1,6 @@
 :_mod-docs-content-type: CONCEPT
-[id="serverless-ossm-traffic-isolation-architecture_context"]
+[id="serverless-ossm-traffic-isolation-architecture_{context}"]
 = High-level architecture
 
 [role="_abstract"]
 The high-level architecture of {ServerlessProductShortName} traffic isolation provided by {SMProductShortName} consists of `AuthorizationPolicy` objects in the `knative-serving`, `knative-eventing`, and the tenants' namespaces, with all the components being part of the {SMProductShortName}. The injected {SMProductShortName} sidecars enforce those rules to isolate network traffic between tenants.
-
-// [id="serverless-ossm-traffic-isolation-architecture-serving"]
-// == Knative Serving
-
-// Knative Serving adheres to the following architecture:
-
-// image::multi-tenancy-service-mesh-serving.png[Knative Serving architecture]
-
-// The following relationships apply:
-
-// . Workloads in project `tenant-2` cannot call workloads in project `tenant-1` directly. Requests are rejected in the Istio proxies of `tenant-1` workloads.
-
-// . Workloads in project `tenant-2` cannot call workloads in project `tenant-1` through ingress gateway. Requests are rejected in the Istio proxies of `tenant-1` workloads.
-
-// . Workloads in project `tenant-2` cannot call workloads in project `tenant-1` through activator. Requests are rejected in the Istio proxy of the activator component. Because ingress gateways are allowed to call the activator, this includes requests from project `tenant-2` through ingress gateway to the activator.
-
-// . `AuthorizationPolicy` objects are applied in this project.
-
-// [id="serverless-ossm-traffic-isolation-architecture-eventing"]
-// == Knative Eventing
-
-// Knative Eventing adheres to the following architecture:
-
-// image::multi-tenancy-service-mesh-eventing.png[Knative Eventing architecture]
-
-// The following relationships apply:
-
-// . Workloads in `tenant-1` project can send events to Eventing brokers, channels, and sinks endpoints in the `tenant-1` project.
-
-// . Eventing sources, triggers, and subscriptions in project `tenant-1` can send events to workloads in the `tenant-1` project.
-
-// . Workloads in the `tenant-1` project cannot send events to Eventing brokers, channels, and sinks endpoints in the `tenant-2` project.
-
-// . Eventing sources, triggers, and subscriptions in the `tenant-2` project cannot send events to workloads in `tenant-1` project.
-
-// . Workloads in the `tenant-1` project cannot call workloads in the `tenant-2` project as well as workloads in the `tenant-2` project cannot call workloads in the `tenant-1` project.
-
-// . `AuthorizationPolicy` objects are applied in this project.

modules/serverless-ossm-traffic-isolation-securing-the-service-mesh.adoc

@@ -5,6 +5,11 @@
 [role="_abstract"]
 Authorization policies and mTLS allow you to secure {SMProductShortName}.
 
+.Prerequisites
+* You have access to an {product-title} account with cluster administrator access.
+* You have set up the {SMProductShortName} 2.x and {ServerlessProductShortName} integration.
+* You have created one or more OpenShift projects for each tenant.
+
 .Procedure
 
 . Make sure that all {product-title} projects of your tenant are part of the same `ServiceMeshMemberRoll` object as members:
@@ -26,11 +31,10 @@ spec:
    - team-bravo-2       # example OpenShift project that belongs th the team-bravo tenant
 ----
 +
-All projects that are part of the mesh must enforce mTLS in strict mode. This forces Istio to only accept connections with a client-certificate present and allows the Service Mesh sidecar to validate the origin using an `AuthorizationPolicy` object.
+All projects that are part of the mesh must enforce mTLS in strict mode. This forces Istio to only accept connections with a client-certificate present and allows the Service Mesh sidecar to validate the origin by using an `AuthorizationPolicy` object.
 
-. Create the configuration with `AuthorizationPolicy` objects in the `knative-serving` and `knative-eventing` namespaces:
+. Create the configuration with `AuthorizationPolicy` objects in the `knative-serving` and `knative-eventing` namespaces and you get an output similar to the following example:
 +
-.Example `knative-default-authz-policies.yaml` configuration file
 [source,yaml]
 ----
 apiVersion: security.istio.io/v1beta1
@@ -213,13 +217,12 @@ spec:
 +
 These policies restrict the access rules for the network communication between {ServerlessProductShortName} system components. Specifically, they enforce the following rules:
 +
---
 * Deny all traffic that is not explicitly allowed in the `knative-serving` and `knative-eventing` namespaces
 * Allow traffic from the `istio-system` and `knative-serving` namespaces to activator
 * Allow traffic from the `knative-serving` namespace to autoscaler
 * Allow health probes for Apache Kafka components in the `knative-eventing` namespace
 * Allow internal traffic for channel-based brokers in the `knative-eventing` namespace
---
+
 
 . Apply the authorization policy configuration:
 +
@@ -230,11 +233,9 @@ $ oc apply -f knative-default-authz-policies.yaml
 
 . Define which OpenShift projects can communicate with each other. For this communication, every OpenShift project of a tenant requires the following:
 +
---
 * One `AuthorizationPolicy` object limiting directly incoming traffic to the tenant's project
 * One `AuthorizationPolicy` object limiting incoming traffic using the activator component of {ServerlessProductShortName} that runs in the `knative-serving` project
 * One `AuthorizationPolicy` object allowing Kubernetes to call `PreStopHooks` on Knative Services
---
 +
 Instead of creating these policies manually, install the `helm` utility and create the necessary resources for each tenant:
 +

modules/serverless-ossm-traffic-isolation-verifying-the-configuration.adoc

@@ -5,6 +5,11 @@
 [role="_abstract"]
 You can use the `curl` command to verify the configuration for network traffic isolation.
 
+.Prerequisites
+* You have access to an {product-title} account with cluster administrator access.
+* You have set up the {SMProductShortName} 2.x and {ServerlessProductShortName} integration.
+* You have created one or more OpenShift projects for each tenant.
+
 [NOTE]
 ====
 The following examples assume having two tenants, each having one namespace, and all part of the `ServiceMeshMemberRoll` object, configured with the resources in the `team-alpha.yaml` and `team-bravo.yaml` files.