openshift · Dhruv-Soni11 · Apr 23, 2025 · May 6, 2025
diff --git a/argo_rollouts/argo-rollouts-overview.adoc b/argo_rollouts/argo-rollouts-overview.adoc
@@ -21,6 +21,12 @@ include::modules/gitops-about-argo-rollout-manager-custom-resources-and-spec.ado
 // Argo Rollouts architecture overview
 include::modules/gitops-argo-rollouts-architecture-overview.adoc[leveloffset=+1]
 
+// Argo Rollouts components
+include::modules/gitops-argo-rollouts-components.adoc[leveloffset=+2]
+
+// Argo Rollouts resources
+include::modules/gitops-argo-rollouts-resources.adoc[leveloffset=+2]
+
 // Argo Rollouts CLI overview
 include::modules/gitops-argo-rollouts-cli-overview.adoc[leveloffset=+1]
 

diff --git a/...-openshift-cluster-by-deploying-an-application-with-cluster-configurations.adoc b/...-openshift-cluster-by-deploying-an-application-with-cluster-configurations.adoc
@@ -59,12 +59,24 @@ include::modules/gitops-additional-permissions-for-cluster-config.adoc[leveloffs
 * xref:../declarative_clusterconfig/customizing-permissions-by-creating-user-defined-cluster-roles-for-cluster-scoped-instances.adoc#customizing-permissions-by-creating-user-defined-cluster-roles-for-cluster-scoped-instances[Customizing permissions by creating user-defined cluster roles for cluster-scoped instances]
 * xref:../declarative_clusterconfig/customizing-permissions-by-creating-aggregated-cluster-roles.adoc#customizing-permissions-by-creating-aggregated-cluster-roles[Customizing permissions by creating aggregated cluster roles]
 
-// Installing OLM Operators using Red Hat OpenShift GitOps
-include::modules/gitops-installing-olm-operators-using-gitops.adoc[leveloffset=+1]
+// Install OLM Operators using Red Hat OpenShift GitOps
+include::modules/gitops-install-olm-operators-using-gitops.adoc[leveloffset=+1]
+
+// Installing cluster-scoped Operators
+include::modules/gitops-installing-cluster-scoped-operators.adoc[leveloffset=+2]
+
+// Installing namespace-scoped Operators
+include::modules/gitops-namespace-scoped-operators.adoc[leveloffset=+2]
 
 // Configuring respectRBAC using Red Hat OpenShift GitOps
 include::modules/gitops-configuring-respect-rbac-using-gitops.adoc[leveloffset=+1]
 
+// Configuring respectRBAC using the CLI
+include::modules/gitops-configuring-respect-rbac-using-the-cli.adoc[leveloffset=+2]
+
+// Configuring respectRBAC by using the web console
+include::modules/gitops-configuring-respect-rbac-using-the-web-console.adoc[leveloffset=+2]
+
 [role="_additional-resources"]
 [id="additional-resources_{context}"]
 == Additional resources

diff --git a/...clusterconfig/customizing-permissions-by-creating-aggregated-cluster-roles.adoc b/...clusterconfig/customizing-permissions-by-creating-aggregated-cluster-roles.adoc
@@ -42,8 +42,15 @@ With {gitops-title} 1.14 and later, as a cluster administrator, you can use aggr
 // Creating aggregated cluster roles
 include::modules/gitops-creating-aggregated-cluster-roles.adoc[leveloffset=+1]
 
+// Enable the creation of aggregated cluster roles
+include::modules/gitops-enable-creation-of-aggregated-cluster-roles.adoc[leveloffset=+2]
+
+// Create user-defined cluster roles and configure user-defined permissions
+include::modules/gitops-create-configure-aggregated-user-defined-permissions.adoc[leveloffset=+2]
+
 // Enabling the creation of aggregated cluster roles
 include::modules/gitops-enabling-the-creation-of-aggregated-cluster-roles.adoc[leveloffset=+1]
+
 [role="_additional-resources"]
 .Additional resources
 * xref:../argocd_instance/setting-up-argocd-instance.adoc#setting-up-argocd-instance[Installing a user-defined Argo CD instance]

diff --git a/modules/gitops-argo-rollouts-architecture-overview.adoc b/modules/gitops-argo-rollouts-architecture-overview.adoc
@@ -20,48 +20,4 @@ The architecture of Argo Rollouts is structured into components and resources. C
 Argo Rollouts include several mechanisms to gather analysis metrics to verify that a new application version is deployed:
 
 * *Prometheus metrics*: The `AnalysisTemplate` CR is configured to connect to Prometheus instances to evaluate the success or failure of one or more metrics.
-* *Kubernetes job metrics*: Argo Rollouts support the Kubernetes `Job` resource to run analysis on resource metrics. You can verify a successful deployment of an application based on the successful run of Kubernetes jobs.
-
-[id="gitops-argo-rollouts-components_{context}"]
-== Argo Rollouts components
-
-Argo Rollouts consists of several components that enable users to practice progressive delivery in {OCP}.
-
-.Argo Rollouts components
-[options="header"]
-|===
-|Name |Description
-|Argo Rollouts controller |The Argo Rollouts Controller is an alternative to the standard `Deployment` resource and coexists alongside it. This controller only responds to changes in the Argo Rollouts resources and manages the `Rollout` CR. The Argo Rollouts Controller does not modify standard deployment resources.
-|AnalysisRun controller |The AnalysisRun controller manages and performs analysis for `AnalysisRun` and `AnalysisTemplate` CRs. It connects a rollout to the metrics provider and defines thresholds for metrics that determine if a deployment update is successful for your application.
-|`Experiment controller` | The `Experiment` controller runs analysis on short-lived replica sets, and manages the `Experiment` custom resource. The controller can also be integrated with the `Rollout` resource by specifying the `experiment` step in the canary deployment `strategy` field.
-|`Service` and `Ingress` controller |The Service controller manages the `Service` resources and the Ingress controller manages the `Ingress` resources modified by Argo Rollouts. These controllers inject additional metadata annotations in the application instances for traffic management.
-|Argo Rollouts CLI and UI |Argo Rollouts supports an `oc/kubectl` plugin called Argo Rollouts CLI. You can use it to interact with resources, such as rollouts, analyses, and experiments, from the command line. It can perform operations, such as `pause`, `promote`, or `retry`. The Argo Rollouts CLI plugin can start a local web UI dashboard in the browser to enhance the experience of visualizing the Argo Rollouts resources.
-|===
-
-[id="gitops-argo-rollouts-resources_{context}"]
-== Argo Rollouts resources
-
-Argo Rollout components manage several resources to enable progressive delivery:
-
-* *Rollouts-specific resources*: For example, `Rollout`, `AnalysisRun`, or `Experiment`.
-* *Kubernetes networking resources*: For example, `Service`, `Ingress`, or `Route` for network traffic shaping. Argo Rollouts integrate with these resources, which are referred to as traffic management.
-
-These resources are essential for customizing the deployment of applications through the `Rollout` CR.
-
-Argo Rollouts support the following actions:
-
-* Route percentage-based traffic for canary deployments.
-* Forward incoming user traffic by using `Service` and `Ingress` resources to the correct application version. 
-* Use multiple mechanisms to collect analysis metrics to validate the deployment of a new version of an application.
-
-.Argo Rollouts resources
-[options="header"]
-|===
-|Name |Description
-|`Rollout` |This CR enables the deployment of applications by using canary or blue-green deployment strategies. It replaces the in-built Kubernetes `Deployment` resource.
-|`AnalysisRun` |This CR is used to perform an analysis and aggregate the results of analysis to guide the user toward the successful deployment delivery of an application. The `AnalysisRun` CR is an instance of the `AnalysisTemplate` CR.
-|`AnalysisTemplate` |The `AnalysisTemplate` CR is a template file that provides instructions on how to query metrics. The result of these instructions is attached to a rollout in the form of the `AnalysisRun` CR. The `AnalysisTemplate` CR can be defined globally on the cluster or on a specific rollout. You can link a list of `AnalysisTemplate` to be used on replica sets by creating an `Experiment` custom resource.
-|`Experiment` |The `Experiment` CR is used to run short-lived analysis on an application during its deployment to ensure the application is deployed correctly. The `Experiment` CR can be used independently or run as part of the `Rollout` CR.
-|`Service` and `Ingress` | Argo Rollouts natively support routing traffic by services and ingresses by using the Service and Ingress controllers.
-|`Route` and `VirtualService` |The OpenShift `Route` and {SMProductName} `VirtualService` resources are used to perform traffic splitting across different application versions.
-|===
+* *Kubernetes job metrics*: Argo Rollouts support the Kubernetes `Job` resource to run analysis on resource metrics. You can verify a successful deployment of an application based on the successful run of Kubernetes jobs.
diff --git a/modules/gitops-argo-rollouts-components.adoc b/modules/gitops-argo-rollouts-components.adoc
@@ -0,0 +1,20 @@
+// Module included in the following assemblies:
+//
+// * argo_rollouts/argo-rollouts-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="gitops-argo-rollouts-components_{context}"]
+= Argo Rollouts components
+
+Argo Rollouts consists of several components that enable users to practice progressive delivery in {OCP}.
+
+.Argo Rollouts components
+[options="header"]
+|===
+|Name |Description
+|Argo Rollouts controller |The Argo Rollouts Controller is an alternative to the standard `Deployment` resource and coexists alongside it. This controller only responds to changes in the Argo Rollouts resources and manages the `Rollout` custom resource (CR). The Argo Rollouts Controller does not modify standard deployment resources.
+|AnalysisRun controller |The AnalysisRun controller manages `AnalysisRun` and `AnalysisTemplate` CRs and performs analysis for them. It connects a rollout to the metrics provider and defines thresholds for metrics that determine if a deployment update is successful for your application.
+|`Experiment controller` | The `Experiment` controller runs analysis on short-lived replica sets and manages the `Experiment` custom resource. You can also integrate this controller with the `Rollout` resource by specifying the `experiment` step in the canary deployment `strategy` field.
+|`Service` and `Ingress` controllers |The Service controller manages the `Service` resources and the Ingress controller manages the `Ingress` resources modified by Argo Rollouts. These controllers inject additional metadata annotations in the application instances for traffic management.
+|Argo Rollouts CLI and UI |Argo Rollouts supports an `oc/kubectl` plugin called Argo Rollouts CLI. You can use it to interact with resources, such as rollouts, analyses, and experiments, from the command line. It can perform operations, such as `pause`, `promote`, or `retry`. The Argo Rollouts CLI plugin can start a local web UI dashboard in the browser to enhance the experience of visualizing the Argo Rollouts resources.
+|===
diff --git a/modules/gitops-argo-rollouts-resources.adoc b/modules/gitops-argo-rollouts-resources.adoc
@@ -0,0 +1,32 @@
+// Module included in the following assemblies:
+//
+// * argo_rollouts/argo-rollouts-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="gitops-argo-rollouts-resources_{context}"]
+= Argo Rollouts resources
+
+Argo Rollouts manage several resources to enable progressive delivery:
+
+* *Rollouts-specific resources*: For example, `Rollout`, `AnalysisRun`, or `Experiment`.
+* *Kubernetes networking resources*: For example, `Service`, `Ingress`, or `Route` for network traffic shaping. Argo Rollouts integrate with these resources, which are referred to as traffic management.
+
+These resources are essential for customizing the deployment of applications through the `Rollout` CR.
+
+Argo Rollouts support the following actions:
+
+* Route percentage-based traffic for canary deployments.
+* Forward incoming user traffic to the correct application version by using `Service` and `Ingress` resources.  
+* Use multiple mechanisms to collect analysis metrics to validate the deployment of a new version of an application.
+
+.Argo Rollouts resources
+[options="header"]
+|===
+|Name |Description
+|`Rollout` |This custom resource (CR) enables the deployment of applications by using canary or blue-green deployment strategies. It replaces the in-built Kubernetes `Deployment` resource.
+|`AnalysisRun` |You can use this CR to perform an analysis and aggregate the results to guide the user in successfully deploying and delivering the application. The `AnalysisRun` CR is an instance of the `AnalysisTemplate` CR.
+|`AnalysisTemplate` |The `AnalysisTemplate` CR is a template that provides instructions about querying metrics. The result of these instructions is attached to a rollout in the form of the `AnalysisRun` CR. The `AnalysisTemplate` CR can be defined globally on the cluster or on a specific rollout. You can link a list of `AnalysisTemplate` resources to be used on replica sets by creating an `Experiment` custom resource.
+|`Experiment` |The `Experiment` CR is used to run short-lived analysis on an application during its deployment to ensure the application is deployed correctly. You can use the `Experiment` CR independently or run it as a part of the `Rollout` CR.
+|`Service` and `Ingress` | Argo Rollouts natively support routing traffic by services and ingresses by using the Service and Ingress controllers.
+|`Route` and `VirtualService` |The OpenShift `Route` and {SMProductName} `VirtualService` resources are used to perform traffic splitting across different application versions.
+|===
diff --git a/modules/gitops-benefits-of-managing-secrets-using-sscsid-with-gitops-overview.adoc b/modules/gitops-benefits-of-managing-secrets-using-sscsid-with-gitops-overview.adoc
@@ -0,0 +1,13 @@
+// Module is included in the following assemblies:
+//
+// * securing_openshift_gitops/managing-secrets-securely-using-sscsid-with-gitops.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="gitops-benefits-of-managing-secrets-using-sscsid-with-gitops-overview_{context}"]
+= Benefits of managing secrets using the Secrets Store CSI driver with {gitops-shortname}
+
+Integrating the SSCSI driver with the {gitops-shortname} Operator provides the following benefits:
+
+* Enhance the security and efficiency of your {gitops-shortname} workflows.
+* Facilitate the secure attachment of secrets into deployment pods as a volume.
+* Ensure that sensitive information is accessed securely and efficiently.
diff --git a/modules/gitops-configuring-respect-rbac-using-gitops.adoc b/modules/gitops-configuring-respect-rbac-using-gitops.adoc
@@ -2,7 +2,7 @@
 //
 // * declarative_clusterconfig/configuring-an-openshift-cluster-by-deploying-an-application-with-cluster-configurations.adoc
 
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: CONCEPT
 [id="gitops-configuring-respect-rbac-using-gitops_{context}"]
 = Configuring respectRBAC using {gitops-title}
 
@@ -14,87 +14,4 @@ You can enable the `respectRBAC` feature by creating an Argo CD instance through
 
 .Prerequisites
 
-Ensure that you created and updated a namespace in the `Subscription` resource, so `Subscription` can host a cluster-scoped Argo CD instance. For more information, see "Using an Argo CD instance to manage cluster-scoped resources".
-
-[id="configuring-respectRBAC-using-the-cli_{context}"]
-== Configuring respectRBAC using the CLI
-
-You can configure the `respectRBAC` feature by using the CLI.
-
-.Procedure
-
-. Create a YAML object file, for example, `argo-cd-resource.yaml`, to configure the `respectRBAC` feature: 
-+
-.Example `ArgoCD` YAML to create `respectRBAC` 
-[source,yaml]
-----
-apiVersion: argoproj.io/v1beta1
-kind: ArgoCD
-metadata:
-  name: example-argocd #<1>
-spec:
-  controller:
-    respectRBAC: strict #<2>
-----
-<1> Specify the name of the Argo CD instance.
-<2> You can specify the value of the `.spec.controller.respectRBAC` key in the `ArgoCD` resource as `normal` or `strict`. Consider setting a value as `normal` to balance accuracy and speed as resource listing is a lightweight operation. Set the value as `strict` if Argo CD reports errors indicating that it cannot access resources when you set the value as `normal`.  Setting `strict` increases the number of API calls to the server and it is more accurate compared to `normal` as Argo CD performs additional validations of RBAC resources to determine permissions.
-
-. Apply the changes to the YAML file by running the following command.
-+
-[source,terminal]
-----
-$ oc apply -f argocd-resource.yaml -n argo-cd-instance #<1>
-----
-<1> Specify the name of the YAML file that includes the `ArgoCD` resource and the namespace that hosts `ArgoCD`.
-+
-. Verify that the status of the `.status.phase` field is `Available` by running the following command:
-+
-[source,terminal]
-----
-$ oc get argocd <argocd_instance_name> -n <argocd_namespace> -o jsonpath='{.status.phase}' #<1>
-----
-<1> Replace `<argocd_instance_name>` with the name of your Argo CD instance for example, `example-argocd`.
-
-. Verify that the `resource.respectRBAC` parameter in the `ConfigMap` resource is updated successfully:
-.. To retrieve the contents of the `argocd-cm` config map, run the following command:
-+
-[source,terminal]
-----
-$ oc get cm argocd-cm -n <argocd_namespace> -o yaml
-----
-.. Verify that the `argocd-cm` `ConfigMap` contains the `resource.respectRBAC` parameter and ensure its value is set to either `strict` or `normal`.
-
-[id="configuring-respectRBAC-using-the-web-UI_{context}"]
-== Configuring respectRBAC by using the web console
-
-You can configure `respectRBAC` in the web console.
-
-.Procedure
-
-. Log in to the {OCP} web console. 
-
-. In the *Administrator* perspective of the web console, click *Operators* -> *Installed Operators*.
-
-. Create or select the project where you want to install the user-defined Argo CD instance from the *Project* list.
-
-. Select *{gitops-title}* from the installed Operators list and click the *Argo CD* tab.
-
-. Configure the `respectRBAC` parameter in the *Argo CD* tab.
-+
-[source,yaml]
-----
-spec:
-  controller:
-    respectRBAC: strict
-----
-
-. Click *Create*.
-+
-After successful installation, verify that the Argo CD instance is listed under the *Argo CD* tab and the *Status* is *Available*.
-
-. After the Argo CD instance is created, verify that the `resource.respectRBAC` parameter in the `ConfigMap` resource is updated successfully by completing the following steps.
-
-.. In the *Administrator* perspective, go to *Workload* -> *ConfigMaps*.
-.. In the *Project* option, select the *Argo CD* namespace.
-.. Select the `argocd-cm` config map.
-.. Select the *YAML* tab to view the `resource.respectRBAC` parameter.
+Ensure that you created and updated a namespace in the `Subscription` resource, so `Subscription` can host a cluster-scoped Argo CD instance. For more information, see "Using an Argo CD instance to manage cluster-scoped resources".