Chapter 5. GitOps 5.1. Red Hat OpenShift GitOps release notes Red Hat OpenShift GitOps is a declarative way to implement continuous deployment for cloud native applications. Red Hat OpenShift GitOps ensures consistency in applications when you deploy them to different clusters in different environments, such as: development, staging, and production. Red Hat OpenShift GitOps helps you automate the following tasks: Ensure that the clusters have similar states for configuration, monitoring, and storage Recover or recreate clusters from a known state Apply or revert configuration changes to multiple OpenShift Container Platform clusters Associate templated configuration with different environments Promote applications across clusters, from staging to production For an overview of Red Hat OpenShift GitOps, see Understanding OpenShift GitOps . 5.1.1. Compatibility and support matrix Some features in this release are currently in Technology Preview . These experimental features are not intended for production use. In the table, features are marked with the following statuses: TP : Technology Preview GA : General Availability NA : Not Applicable Important In OpenShift Container Platform 4.13, the stable channel has been removed. Before upgrading to OpenShift Container Platform 4.13, if you are already on the stable channel, choose the appropriate channel and switch to it. OpenShift GitOps Component Versions OpenShift Versions Version kam Helm Kustomize Argo CD ApplicationSet Dex RH SSO 1.8.0 0.0.47 TP 3.10.0 GA 4.5.7 GA 2.6.3 GA NA 2.35.1 GA 7.5.1 GA 4.10-4.13 1.7.0 0.0.46 TP 3.10.0 GA 4.5.7 GA 2.5.4 GA NA 2.35.1 GA 7.5.1 GA 4.10-4.12 1.6.0 0.0.46 TP 3.8.1 GA 4.4.1 GA 2.4.5 GA GA and included in ArgoCD component 2.30.3 GA 7.5.1 GA 4.8-4.11 1.5.0 0.0.42 TP 3.8.0 GA 4.4.1 GA 2.3.3 GA 0.4.1 TP 2.30.3 GA 7.5.1 GA 4.8-4.11 1.4.0 0.0.41 TP 3.7.1 GA 4.2.0 GA 2.2.2 GA 0.2.0 TP 2.30.0 GA 7.4.0 GA 4.7-4.10 1.3.0 0.0.40 TP 3.6.0 GA 4.2.0 GA 2.1.2 GA 0.2.0 TP 2.28.0 GA 7.4.0 GA 4.7-4.9, 4.6 with limited GA support 1.2.0 0.0.38 TP 3.5.0 GA 3.9.4 GA 2.0.5 GA 0.1.0 TP NA 7.4.0 GA 4.8 1.1.0 0.0.32 TP 3.5.0 GA 3.9.4 GA 2.0.0 GA NA NA NA 4.7 kam is the Red Hat OpenShift GitOps Application Manager command-line interface (CLI). RH SSO is an abbreviation for Red Hat SSO. 5.1.1.1. Technology Preview features The features mentioned in the following table are currently in Technology Preview (TP). These experimental features are not intended for production use. Table 5.1. Technology Preview tracker Feature TP in Red Hat OpenShift GitOps versions GA in Red Hat OpenShift GitOps versions ApplicationSet Progressive Rollout Strategy 1.8.0 NA Multiple sources for an application 1.8.0 NA Argo CD applications in non-control plane namespaces 1.7.0 NA Argo CD Notifications controller 1.6.0 NA The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console 1.1.0 NA 5.1.2. Making open source more inclusive Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright's message . 5.1.3. Release notes for Red Hat OpenShift GitOps 1.8.4 Red Hat OpenShift GitOps 1.8.4 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13. 5.1.3.1. New features The current release adds the following improvements: With this update, the bundled Argo CD has been updated to version 2.6.13. 5.1.3.2. Fixed issues The following issues have been resolved in the current release: Before this update, Argo CD was becoming unresponsive when there was an increase in namespaces and applications. The functions competing for resources caused a deadlock. This update fixes the issue by removing the deadlock. Now, you should not experience crashes or unresponsiveness when there is an increase in namespaces or applications. GITOPS-3192 Before this update, the Argo CD application controller resource could suddenly stop working when resynchronizing applications. This update fixes the issue by adding logic to prevent a cluster cache deadlock. Now, applications should resynchronize successfully. GITOPS-3052 Before this update, there was a mismatch in the RSA key for known hosts in the argocd-ssh-known-hosts-cm config map. This update fixes the issue by matching the RSA key with the upstream project. Now, you can use the default RSA keys on default deployments. GITOPS-3144 Before this update, an old Redis image version was used when deploying the Red Hat OpenShift GitOps Operator, which resulted in vulnerabilities. This update fixes the vulnerabilities on Redis by upgrading it to the latest version of the registry.redhat.io/rhel-8/redis-6 image. GITOPS-3069 Before this update, users could not connect to Microsoft Team Foundation Server (TFS) type Git repositories through Argo CD deployed by the Operator. This update fixes the issue by updating the Git version to 2.39.3 in the Operator. Now, you can set the Force HTTP basic auth flag during repository configurations to connect with the TFS type Git repositories. GITOPS-1315 5.1.3.3. Known issues Currently, Red Hat OpenShift GitOps 1.8.4 is not available in the latest channel of OpenShift Container Platform 4.10 and 4.11. The latest channel is taken by GitOps 1.9.z, which is only released on OpenShift Container Platform 4.12 and later versions. As a workaround, switch to the gitops-1.8 channel to get the new update. GITOPS-3158 5.1.4. Release notes for Red Hat OpenShift GitOps 1.8.3 Red Hat OpenShift GitOps 1.8.3 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13. 5.1.4.1. Errata updates 5.1.4.1.1. RHBA-2023:3206 and RHSA-2023:3229 - Red Hat OpenShift GitOps 1.8.3 security update advisory Issued: 2023-05-18 The list of security fixes that are included in this release is documented in the following advisories: RHBA-2023:3206 RHSA-2023:3229 If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release: USD oc describe deployment gitops-operator-controller-manager -n openshift-operators 5.1.4.2. Fixed issues Before this update, when Autoscale was enabled and the horizontal pod autoscaler (HPA) controller tried to edit the replica settings in server deployment, the Operator overwrote it. In addition, any changes specified to the autoscaler parameters were not propagated correctly to the HPA on the cluster. This update fixes the issue. Now the Operator reconciles on replica drift only if Autoscale is disabled and the HPA parameters are updated correctly. GITOPS-2629 5.1.5. Release notes for Red Hat OpenShift GitOps 1.8.2 Red Hat OpenShift GitOps 1.8.2 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13. 5.1.5.1. Fixed issues The following issues have been resolved in the current release: Before this update, when you configured Dex using the .spec.dex parameter and tried to log in to the Argo CD UI by using the LOG IN VIA OPENSHIFT option, you were not able to log in. This update fixes the issue. Important The spec.dex parameter in the ArgoCD CR is deprecated. In a future release of Red Hat OpenShift GitOps v1.9, configuring Dex using the spec.dex parameter in the ArgoCD CR is planned to be removed. Consider using the .spec.sso parameter instead. See "Enabling or disabling Dex using .spec.sso". GITOPS-2761 Before this update, the cluster and kam CLI pods failed to start with a new installation of Red Hat OpenShift GitOps v1.8.0 on the OpenShift Container Platform 4.10 cluster. This update fixes the issue and now all pods run as expected. GITOPS-2762 5.1.6. Release notes for Red Hat OpenShift GitOps 1.8.1 Red Hat OpenShift GitOps 1.8.1 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13. 5.1.6.1. Errata updates 5.1.6.1.1. RHSA-2023:1452 - Red Hat OpenShift GitOps 1.8.1 security update advisory Issued: 2023-03-23 The list of security fixes that are included in this release is documented in the RHSA-2023:1452 advisory. If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release: USD oc describe deployment gitops-operator-controller-manager -n openshift-operators 5.1.7. Release notes for Red Hat OpenShift GitOps 1.8.0 Red Hat OpenShift GitOps 1.8.0 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13. 5.1.7.1. New features The current release adds the following improvements: With this update, you can add support for the ApplicationSet Progressive Rollout Strategy feature. Using this feature, you can enhance the ArgoCD ApplicationSet resource to embed a rollout strategy for a progressive application resource update after you modify the ApplicationSet spec or Application templates. When you enable this feature, applications are updated in a declarative order instead of simultaneously. GITOPS-956 Important ApplicationSet Progressive Rollout Strategy is a Technology Preview feature. With this update, the Application environments page in the Developer perspective of the OpenShift Container Platform web console is decoupled from the Red Hat OpenShift GitOps Application Manager command-line interface (CLI), kam . You do not have to use the kam CLI to generate Application Environment manifests for the environments to show up in the Developer perspective of the OpenShift Container Platform web console. You can use your own manifests, but the environments must still be represented by namespaces. In addition, specific labels and annotations are still needed. GITOPS-1785 With this update, the Red Hat OpenShift GitOps Operator and the kam CLI are now available to use on ARM architecture on OpenShift Container Platform. GITOPS-1688 Important spec.sso.provider: keycloak is not yet supported on ARM. With this update, you can enable workload monitoring for specific Argo CD instances by setting the .spec.monitoring.enabled flag value to true . As a result, the Operator creates a PrometheusRule object that contains alert rules for each Argo CD component. These alert rules trigger an alert when the replica count of the corresponding component has drifted from the desired state for a certain amount of time. The Operator will not overwrite the changes made to the PrometheusRule object by the users. GITOPS-2459 With this update, you can pass command arguments to the repo server deployment using the Argo CD CR. GITOPS-2445 For example: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: repo: extraRepoCommandArgs: - --max.combined.directory.manifests.size - 10M 5.1.7.2. Fixed issues The following issues have been resolved in the current release: Before this update, you could set the ARGOCD_GIT_MODULES_ENABLED environment variable only on the openshift-gitops-repo-server pod and not on the ApplicationSet Controller pod. As a result, when using the Git generator, Git submodules were cloned during the generation of child applications because the variable was missing from the ApplicationSet Controller environment. In addition, if the credentials required to clone these submodules were not configured in ArgoCD, the application generation failed. This update fixes the issue; you can now add any environment variables such as ArgoCD_GIT_MODULES_ENABLED to the ApplicationSet Controller pod using the Argo CD CR. The ApplicationSet Controller pod then successfully generates child applications from the cloned repository and no submodule is cloned in the process. GITOPS-2399 For example: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: applicationSet: env: - name: ARGOCD_GIT_MODULES_ENABLED value: "true" Before this update, while installing the Red Hat OpenShift GitOps Operator v1.7.0, the default argocd-cm.yml config map file created for authenticating Dex contained the base64-encoded client secret in the format of a key:value pair. This update fixes this issue by not storing the client secret in the default argocd-cm.yml config map file. Instead, the client secret is inside an argocd-secret object now, and you can reference it inside the configuration map as a secret name. GITOPS-2570 5.1.7.3. Known issues When you deploy applications using your manifests without using the kam CLI and view the applications in the Application environments page in the Developer perspective of the OpenShift Container Platform web console, the Argo CD URL to the corresponding application does not load the page as expected from the Argo CD icon in the card. GITOPS-2736 5.1.8. Release notes for Red Hat OpenShift GitOps 1.7.4 Red Hat OpenShift GitOps 1.7.4 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12. 5.1.8.1. Errata updates 5.1.8.1.1. RHSA-2023:1454 - Red Hat OpenShift GitOps 1.7.4 security update advisory Issued: 2023-03-23 The list of security fixes that are included in this release is documented in the RHSA-2023:1454 advisory. If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release: USD oc describe deployment gitops-operator-controller-manager -n openshift-operators 5.1.9. Release notes for Red Hat OpenShift GitOps 1.7.3 Red Hat OpenShift GitOps 1.7.3 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12. 5.1.9.1. Errata updates 5.1.9.1.1. RHSA-2023:1454 - Red Hat OpenShift GitOps 1.7.3 security update advisory Issued: 2023-03-23 The list of security fixes that are included in this release is documented in the RHSA-2023:1454 advisory. If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release: USD oc describe deployment gitops-operator-controller-manager -n openshift-operators 5.1.10. Release notes for Red Hat OpenShift GitOps 1.7.1 Red Hat OpenShift GitOps 1.7.1 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12. 5.1.10.1. Errata updates 5.1.10.1.1. RHSA-2023:0467 - Red Hat OpenShift GitOps 1.7.1 security update advisory Issued: 2023-01-25 The list of security fixes that are included in this release is documented in the RHSA-2023:0467 advisory. If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release: USD oc describe deployment gitops-operator-controller-manager -n openshift-operators 5.1.11. Release notes for Red Hat OpenShift GitOps 1.7.0 Red Hat OpenShift GitOps 1.7.0 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12. 5.1.11.1. New features The current release adds the following improvements: With this update, you can add environment variables to the Notifications controller. GITOPS-2313 With this update, the default nodeSelector "kubernetes.io/os": "linux" key-value pair is added to all workloads such that they only schedule on Linux nodes. In addition, any custom node selectors are added to the default and take precedence if they have the same key. GITOPS-2215 With this update, you can set custom node selectors in the Operator workloads by editing their GitopsService custom resource. GITOPS-2164 With this update, you can use the RBAC policy matcher mode to select from the following options: glob (default) and regex . GITOPS-1975 With this update, you can customize resource behavior using the following additional subkeys: Subkey Key form Mapped field in argocd-cm resourceHealthChecks resource.customizations.health.<group_kind> resource.customizations.health resourceIgnoreDifferences resource.customizations.ignoreDifferences.<group_kind> resource.customizations.ignoreDifferences resourceActions resource.customizations.actions.<group_kind> resource.customizations.actions GITOPS-1561 Note In future releases, there is a possibility to deprecate the old method of customizing resource behavior by using only resourceCustomization and not subkeys. With this update, to use the Environments page in the Developer perspective, you must upgrade if you are using a Red Hat OpenShift GitOps version prior to 1.7 and OpenShift Container Platform 4.15 or above. GITOPS-2415 With this update, you can create applications, which are managed by the same control plane Argo CD instance, in any namespace in the same cluster. As an administrator, perform the following actions to enable this update: Add the namespace to the .spec.sourceNamespaces attribute for a cluster-scoped Argo CD instance that manages the application. Add the namespace to the .spec.sourceNamespaces attribute in the AppProject custom resource that is associated with the application. GITOPS-2341 Important Argo CD applications in non-control plane namespaces is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . With this update, Argo CD supports the Server-Side Apply feature, which helps users to perform the following tasks: Manage large resources which are too big for the allowed annotation size of 262144 bytes. Patch an existing resource that is not managed or deployed by Argo CD. You can configure this feature at application or resource level. GITOPS-2340 5.1.11.2. Fixed issues The following issues have been resolved in the current release: Before this update, Red Hat OpenShift GitOps releases were affected by an issue of Dex pods failing with CreateContainerConfigError error when the anyuid SCC was assigned to the Dex service account. This update fixes the issue by assigning a default user id to the Dex container. GITOPS-2235 Before this update, Red Hat OpenShift GitOps used the RHSSO (Keycloak) through OIDC in addition to Dex. However, with a recent security fix, the certificate of RHSSO could not be validated when configured with a certificate not signed by one of the well-known certificate authorities. This update fixes the issue; you can now provide a custom certificate to verify the KeyCloak's TLS certificate while communicating with it. In addition, you can add rootCA to the Argo CD custom resource .spec.keycloak.rootCA field. The Operator reconciles such changes and updates the oidc.config in argocd-cm config map with the PEM encoded root certificate. GITOPS-2214 Example Argo CD with Keycloak configuration: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: sso: keycloak: rootCA: '<PEM encoded root certificate>' provider: keycloak ....... ....... Before this update, the application controllers restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the statefulset application controller. GITOPS-2153 5.1.11.3. Known issues Before this update, the Operator did not reconcile the mountsatoken and ServiceAccount settings for the repository server. While this has been fixed, deletion of the service account does not revert to the default. GITOPS-1873 Workaround: Manually set the spec.repo.serviceaccountfield to thedefault service account. GITOPS-2452 5.1.12. Release notes for Red Hat OpenShift GitOps 1.6.7 Red Hat OpenShift GitOps 1.6.7 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.12.1. Fixed issues The following issue has been resolved in the current release: Before this update, all versions of the Argo CD Operator, starting with v0.5.0 were vulnerable to an information disclosure flaw. As a result, unauthorized users could enumerate application names by inspecting API error messages and use the discovered application names as the starting point of another attack. For example, the attacker might use their knowledge of an application name to convince an administrator to grant higher privileges. This update fixes the CVE-2022-41354 error. GITOPS-2635 , CVE-2022-41354 5.1.13. Release notes for Red Hat OpenShift GitOps 1.6.6 Red Hat OpenShift GitOps 1.6.6 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.13.1. Fixed issues The following issue has been resolved in the current release: Before this update, all versions of the Argo CD Operator, starting with v0.5.0 were vulnerable to an information disclosure flaw. As a result, unauthorized users could enumerate application names by inspecting API error messages and use the discovered application names as the starting point of another attack. For example, the attacker might use their knowledge of an application name to convince an administrator to grant higher privileges. This update fixes the CVE-2022-41354 error. GITOPS-2635 , CVE-2022-41354 5.1.14. Release notes for Red Hat OpenShift GitOps 1.6.4 Red Hat OpenShift GitOps 1.6.4 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.14.1. Fixed issues Before this update, all versions of Argo CD v1.8.2 and later were vulnerable to an improper authorization bug. As a result, Argo CD would accept tokens for audiences who might not be intended to access the cluster. This issue is now fixed. CVE-2023-22482 5.1.15. Release notes for Red Hat OpenShift GitOps 1.6.2 Red Hat OpenShift GitOps 1.6.2 is now available on OpenShift Container Platform 4.8, 4.9, 4.10 and 4.11. 5.1.15.1. New features This release removes the DISABLE_DEX environment variable from the openshift-gitops-operator CSV file. As a result, this environment variable is no longer set when you perform a fresh installation of Red Hat OpenShift GitOps. GITOPS-2360 5.1.15.2. Fixed issues The following issues have been resolved in the current release: Before this update, the subscription health check was marked degraded for missing InstallPlan when more than 5 Operators were installed in a project. This update fixes the issue. GITOPS-2018 Before this update, the Red Hat OpenShift GitOps Operator would spam the cluster with a deprecation notice warning whenever it detected that an Argo CD instance used deprecated fields. This update fixes this issue and shows only one warning event for each instance that detects a field. GITOPS-2230 From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2352 5.1.16. Release notes for Red Hat OpenShift GitOps 1.6.1 Red Hat OpenShift GitOps 1.6.1 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.16.1. Fixed issues The following issues have been resolved in the current release: Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller StatefulSet object. GITOPS-2153 Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak's TLS certificate when communicating with it. You can add the rootCA to the Argo CD custom resource .spec.keycloak.rootCA field. The Operator reconciles this change and updates the oidc.config field in the argocd-cm ConfigMap with the PEM-encoded root certificate. GITOPS-2214 Note Restart the Argo CD server pod after updating the .spec.keycloak.rootCA field. For example: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: | ---- BEGIN CERTIFICATE ---- This is a dummy certificate Please place this section with appropriate rootCA ---- END CERTIFICATE ---- server: route: enabled: true Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2277 Before this update, the Dex pods failed to start with CreateContainerConfigError when an SCC of anyuid was assigned to the Dex ServiceAccount resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235 5.1.17. Release notes for Red Hat OpenShift GitOps 1.6.0 Red Hat OpenShift GitOps 1.6.0 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.17.1. New features The current release adds the following improvements: Previously, the Argo CD ApplicationSet controller was a technology preview (TP) feature. With this update, it is a general availability (GA) feature. GITOPS-1958 With this update, the latest releases of the Red Hat OpenShift GitOps are available in latest and version-based channels. To get these upgrades, update the channel parameter in the Subscription object YAML file: change its value from stable to latest or a version-based channel such as gitops-1.6 . GITOPS-1791 With this update, the parameters of the spec.sso field that controlled the keycloak configurations are moved to .spec.sso.keycloak . The parameters of the .spec.dex field have been added to .spec.sso.dex . Start using .spec.sso.provider to enable or disable Dex. The .spec.dex parameters are deprecated and planned to be removed in version 1.9, along with the DISABLE_DEX and .spec.sso fields for keycloak configuration. GITOPS-1983 With this update, the Argo CD Notifications controller is available as an optional workload that can be enabled or disabled by using the .spec.notifications.enabled parameter in the Argo CD custom resource. The Argo CD Notifications controller is available as a Technical Preview feature. GITOPS-1917 Important Argo CD Notifications controller is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . With this update, resource exclusions for Tekton pipeline runs and tasks runs are added by default. Argo CD, prunes these resources by default. These resource exclusions are added to the new Argo CD instances that are created from the OpenShift Container Platform. If the instances are created from the CLI, the resources are not added. GITOPS-1876 With this update, you can select the tracking method that by Argo CD uses by setting the resourceTrackingMethod parameter in the Operand's specification. GITOPS-1862 With this update, you can add entries to the argocd-cm configMap using the extraConfig field of Red Hat OpenShift GitOps Argo CD custom resource. The entries specified are reconciled to the live config-cm configMap without validations. GITOPS-1964 With this update, on OpenShift Container Platform 4.11, the Red Hat OpenShift GitOps Environments page in the Developer perspective shows history of the successful deployments of the application environments, along with links to the revision for each deployment. GITOPS-1269 With this update, you can manage resources with Argo CD that are also being used as template resources or "source" by an Operator. GITOPS-982 With this update, the Operator will now configure the Argo CD workloads with the correct permissions to satisfy the Pod Security Admission that has been enabled for Kubernetes 1.24. GITOPS-2026 With this update, Config Management Plugins 2.0 is supported. You can use the Argo CD custom resource to specify sidebar containers for the repo server. GITOPS-776 With this update, all communication between the Argo CD components and the Redis cache are properly secured using modern TLS encryption. GITOPS-720 This release of Red Hat OpenShift GitOps adds support for IBM Z and IBM Power on OpenShift Container Platform 4.10. Currently, installations in restricted environments are not supported on IBM Z and IBM Power. 5.1.17.2. Fixed issues The following issues have been resolved in the current release: Before this update, the system:serviceaccount:argocd:gitops-argocd-application-controller cannot create resource "prometheusrules" in API group monitoring.coreos.com in the namespace webapps-dev . This update fixes this issue and Red Hat OpenShift GitOps is now able to manage all resources from the monitoring.coreos.com API group. GITOPS-1638 Before this update, while reconciling cluster permissions, if a secret belonged to a cluster config instance it was deleted. This update fixes this issue. Now, the namespaces field from the secret is deleted instead of the secret. GITOPS-1777 Before this update, if you installed the HA variant of Argo CD through the Operator, the Operator created the Redis StatefulSet object with podAffinity rules instead of podAntiAffinity rules. This update fixes this issue and now the Operator creates the Redis StatefulSet with podAntiAffinity rules. GITOPS-1645 Before this update, Argo CD ApplicationSet had too many ssh Zombie processes. This update fixes this issue: it adds tini, a simple init daemon that spawns processes and reaps zombies, to the ApplicationSet controller. This ensures that a SIGTERM signal is properly passed to the running process, preventing it from being a zombie process. GITOPS-2108 5.1.17.3. Known issues Red Hat OpenShift GitOps Operator can make use of RHSSO (KeyCloak) through OIDC in addition to Dex. However, with a recent security fix applied, the certificate of RHSSO cannot be validated in some scenarios. GITOPS-2214 As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification. spec: extraConfig: oidc.tls.insecure.skip.verify: "true" ... 5.1.18. Release notes for Red Hat OpenShift GitOps 1.5.9 Red Hat OpenShift GitOps 1.5.9 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.18.1. Fixed issues Before this update, all versions of Argo CD v1.8.2 and later were vulnerable to an improper authorization bug. As a result, Argo CD would accept tokens for users who might not be authorized to access the cluster. This issue is now fixed. CVE-2023-22482 5.1.19. Release notes for Red Hat OpenShift GitOps 1.5.7 Red Hat OpenShift GitOps 1.5.7 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.19.1. Fixed issues The following issues have been resolved in the current release: From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2353 5.1.20. Release notes for Red Hat OpenShift GitOps 1.5.6 Red Hat OpenShift GitOps 1.5.6 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.20.1. Fixed issues The following issues have been resolved in the current release: Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller StatefulSet object. GITOPS-2153 Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak's TLS certificate when communicating with it. You can add the rootCA to the Argo CD custom resource .spec.keycloak.rootCA field. The Operator reconciles this change and updates the oidc.config field in the argocd-cm ConfigMap with the PEM-encoded root certificate. GITOPS-2214 Note Restart the Argo CD server pod after updating the .spec.keycloak.rootCA field. For example: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: | ---- BEGIN CERTIFICATE ---- This is a dummy certificate Please place this section with appropriate rootCA ---- END CERTIFICATE ---- server: route: enabled: true Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2278 Before this update, the Dex pods failed to start with CreateContainerConfigError when an SCC of anyuid was assigned to the Dex ServiceAccount resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235 5.1.21. Release notes for Red Hat OpenShift GitOps 1.5.5 Red Hat OpenShift GitOps 1.5.5 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.21.1. New features The current release adds the following improvements: With this update, the bundled Argo CD has been updated to version 2.3.7. 5.1.21.2. Fixed issues The following issues have been resolved in the current release: Before this update, the redis-ha-haproxy pods of an ArgoCD instance failed when more restrictive SCCs were present in the cluster. This update fixes the issue by updating the security context in workloads. GITOPS-2034 5.1.21.3. Known issues Red Hat OpenShift GitOps Operator can use RHSSO (KeyCloak) with OIDC and Dex. However, with a recent security fix applied, the Operator cannot validate the RHSSO certificate in some scenarios. GITOPS-2214 As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification. apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: extraConfig: "admin.enabled": "true" ... 5.1.22. Release notes for Red Hat OpenShift GitOps 1.5.4 Red Hat OpenShift GitOps 1.5.4 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.22.1. Fixed issues The following issues have been resolved in the current release: Before this update, the Red Hat OpenShift GitOps was using an older version of the REDIS 5 image tag. This update fixes the issue and upgrades the rhel8/redis-5 image tag. GITOPS-2037 5.1.23. Release notes for Red Hat OpenShift GitOps 1.5.3 Red Hat OpenShift GitOps 1.5.3 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.23.1. Fixed issues The following issues have been resolved in the current release: Before this update, all unpatched versions of Argo CD v1.0.0 and later were vulnerable to a cross-site scripting bug. As a result, an unauthorized user would be able to inject a javascript link in the UI. This issue is now fixed. CVE-2022-31035 Before this update, all versions of Argo CD v0.11.0 and later were vulnerable to multiple attacks when SSO login was initiated from the Argo CD CLI or the UI. This issue is now fixed. CVE-2022-31034 Before this update, all unpatched versions of Argo CD v0.7 and later were vulnerable to a memory consumption bug. As a result, an unauthorized user would be able to crash the Argo CD's repo-server. This issue is now fixed. CVE-2022-31016 Before this update, all unpatched versions of Argo CD v1.3.0 and later were vulnerable to a symlink-following bug. As a result, an unauthorized user with repository write access would be able to leak sensitive YAML files from Argo CD's repo-server. This issue is now fixed. CVE-2022-31036 5.1.24. Release notes for Red Hat OpenShift GitOps 1.5.2 Red Hat OpenShift GitOps 1.5.2 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.24.1. Fixed issues The following issues have been resolved in the current release: Before this update, images referenced by the redhat-operator-index were missing. This issue is now fixed. GITOPS-2036 5.1.25. Release notes for Red Hat OpenShift GitOps 1.5.1 Red Hat OpenShift GitOps 1.5.1 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.25.1. Fixed issues The following issues have been resolved in the current release: Before this update, if Argo CD's anonymous access was enabled, an unauthenticated user was able to craft a JWT token and get full access to the Argo CD instance. This issue is fixed now. CVE-2022-29165 Before this update, an unauthenticated user was able to display error messages on the login screen while SSO was enabled. This issue is now fixed. CVE-2022-24905 Before this update, all unpatched versions of Argo CD v0.7.0 and later were vulnerable to a symlink-following bug. As a result, an unauthorized user with repository write access would be able to leak sensitive files from Argo CD's repo-server. This issue is now fixed. CVE-2022-24904 5.1.26. Release notes for Red Hat OpenShift GitOps 1.5.0 Red Hat OpenShift GitOps 1.5.0 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11. 5.1.26.1. New features The current release adds the following improvements: This enhancement upgrades Argo CD to version 2.3.3 . GITOPS-1708 This enhancement upgrades Dex to version 2.30.3 . GITOPS-1850 This enhancement upgrades Helm to version 3.8.0 . GITOPS-1709 This enhancement upgrades Kustomize to version 4.4.1 . GITOPS-1710 This enhancement upgrades Application Set to version 0.4.1 . With this update, a new channel by the name latest has been added that provides the latest release of the Red Hat OpenShift GitOps. For GitOps v1.5.0, the Operator is pushed to gitops-1.5 , latest channel, and the existing stable channel. From GitOps v1.6 all the latest releases will be pushed only to the latest channel and not the stable channel. GITOPS-1791 With this update, the new CSV adds the olm.skipRange: '>=1.0.0 <1.5.0' annotation. As a result, all the release versions will be skipped. The Operator upgrades to v1.5.0 directly. GITOPS-1787 With this update, the Operator updates the Red Hat Single Sign-On (RH-SSO) to version v7.5.1 including the following enhancements: You can log in to Argo CD using the OpenShift credentials including the kube:admin credential. The RH-SSO supports and configures Argo CD instances for Role-based Access Control (RBAC) using OpenShift groups. The RH-SSO honors the HTTP_Proxy environment variables. You can use the RH-SSO as an SSO for Argo CD running behind a proxy. GITOPS-1330 With this update, a new .host URL field is added to the .status field of the Argo CD operand. When a route or ingress is enabled with the priority given to route, then the new URL field displays the route. If no URL is provided from the route or ingress, the .host field is not displayed. When the route or ingress is configured, but the corresponding controller is not set up properly and is not in the Ready state or does not propagate its URL, the value of the .status.host field in the operand indicates as Pending instead of displaying the URL. This affects the overall status of the operand by making it Pending instead of Available . GITOPS-654 5.1.26.2. Fixed issues The following issues have been resolved in the current release: Before this update, RBAC rules specific to AppProjects would not allow the use of commas for the subject field of the role, thus preventing bindings to the LDAP account. This update fixes the issue and you can now specify complex role bindings in AppProject specific RBAC rules. GITOPS-1771 Before this update, when a DeploymentConfig resource is scaled to 0 , Argo CD displayed it in a progressing state with a health status message as "replication controller is waiting for pods to run" . This update fixes the edge case and the health check now reports the correct health status of the DeploymentConfig resource. GITOPS-1738 Before this update, the TLS certificate in the argocd-tls-certs-cm configuration map was deleted by the Red Hat OpenShift GitOps unless the certificate was configured in the ArgoCD CR specification tls.initialCerts field. This issue is fixed now. GITOPS-1725 Before this update, while creating a namespace with the managed-by label it created a lot of RoleBinding resources on the new namespace. This update fixes the issue and now Red Hat OpenShift GitOps removes the irrelevant Role and RoleBinding resources created by the versions. GITOPS-1550 Before this update, the TLS certificate of the route in pass-through mode did not have a CA name. As a result, Firefox 94 and later failed to connect to Argo CD UI with error code SEC_ERROR_BAD_DER . This update fixes the issue. You must delete the <openshift-gitops-ca> secrets and let it recreate. Then, you must delete the <openshift-gitops-tls> secrets. After the Red Hat OpenShift GitOps recreates it, the Argo CD UI is accessible by Firefox again. GITOPS-1548 5.1.26.3. Known issues Argo CD .status.host field is not updated when an Ingress resource is in use instead of a Route resource on OpenShift clusters. GITOPS-1920 5.1.27. Release notes for Red Hat OpenShift GitOps 1.4.13 Red Hat OpenShift GitOps 1.4.13 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.27.1. Fixed issues The following issues have been resolved in the current release: From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2354 5.1.28. Release notes for Red Hat OpenShift GitOps 1.4.12 Red Hat OpenShift GitOps 1.4.12 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.28.1. Fixed issues The following issues have been resolved in the current release: Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller StatefulSet object. GITOPS-2153 Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak's TLS certificate when communicating with it. You can add the rootCA to the Argo CD custom resource .spec.keycloak.rootCA field. The Operator reconciles this change and updates the oidc.config field in the argocd-cm ConfigMap with the PEM-encoded root certificate. GITOPS-2214 Note Restart the Argo CD server pod after updating the .spec.keycloak.rootCA field. For example: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: | ---- BEGIN CERTIFICATE ---- This is a dummy certificate Please place this section with appropriate rootCA ---- END CERTIFICATE ---- server: route: enabled: true Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2276 Before this update, the Dex pods failed to start with CreateContainerConfigError when an SCC of anyuid was assigned to the Dex ServiceAccount resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235 5.1.29. Release notes for Red Hat OpenShift GitOps 1.4.11 Red Hat OpenShift GitOps 1.4.11 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.29.1. New features The current release adds the following improvements: With this update, the bundled Argo CD has been updated to version 2.2.12. 5.1.29.2. Fixed issues The following issues have been resolved in the current release: Before this update, the redis-ha-haproxy pods of an ArgoCD instance failed when more restrictive SCCs were present in the cluster. This update fixes the issue by updating the security context in workloads. GITOPS-2034 5.1.29.3. Known issues Red Hat OpenShift GitOps Operator can use RHSSO (KeyCloak) with OIDC and Dex. However, with a recent security fix applied, the Operator cannot validate the RHSSO certificate in some scenarios. GITOPS-2214 As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification. apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: extraConfig: "admin.enabled": "true" ... 5.1.30. Release notes for Red Hat OpenShift GitOps 1.4.6 Red Hat OpenShift GitOps 1.4.6 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.30.1. Fixed issues The following issue has been resolved in the current release: The base images are updated to the latest version to avoid OpenSSL flaw link: (CVE-2022-0778) . Note To install the current release of Red Hat OpenShift GitOps 1.4 and receive further updates during its product life cycle, switch to the GitOps-1.4 channel. 5.1.31. Release notes for Red Hat OpenShift GitOps 1.4.5 Red Hat OpenShift GitOps 1.4.5 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.31.1. Fixed issues Warning You should directly upgrade to Red Hat OpenShift GitOps v1.4.5 from Red Hat OpenShift GitOps v1.4.3. Do not use Red Hat OpenShift GitOps v1.4.4 in a production environment. Major issues that affected Red Hat OpenShift GitOps v1.4.4 are fixed in Red Hat OpenShift GitOps 1.4.5. The following issue has been resolved in the current release: Before this update, Argo CD pods were stuck in the ErrImagePullBackOff state. The following error message was shown: This issue is now fixed. GITOPS-1848 5.1.32. Release notes for Red Hat OpenShift GitOps 1.4.3 Red Hat OpenShift GitOps 1.4.3 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.32.1. Fixed issues The following issue has been resolved in the current release: Before this update, the TLS certificate in the argocd-tls-certs-cm configuration map was deleted by the Red Hat OpenShift GitOps unless the certificate was configured in the ArgoCD CR specification tls.initialCerts field. This update fixes this issue. GITOPS-1725 5.1.33. Release notes for Red Hat OpenShift GitOps 1.4.2 Red Hat OpenShift GitOps 1.4.2 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.33.1. Fixed issues The following issue has been resolved in the current release: Before this update, the Route resources got stuck in Progressing Health status if more than one Ingress were attached to the route. This update fixes the health check and reports the correct health status of the Route resources. GITOPS-1751 5.1.34. Release notes for Red Hat OpenShift GitOps 1.4.1 Red Hat OpenShift GitOps 1.4.1 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.34.1. Fixed issues The following issue has been resolved in the current release: Red Hat OpenShift GitOps Operator v1.4.0 introduced a regression which removes the description fields from spec for the following CRDs: argoproj.io_applications.yaml argoproj.io_appprojects.yaml argoproj.io_argocds.yaml Before this update, when you created an AppProject resource using the oc create command, the resource failed to synchronize due to the missing description fields. This update restores the missing description fields in the preceding CRDs. GITOPS-1721 5.1.35. Release notes for Red Hat OpenShift GitOps 1.4.0 Red Hat OpenShift GitOps 1.4.0 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10. 5.1.35.1. New features The current release adds the following improvements. This enhancement upgrades the Red Hat OpenShift GitOps Application Manager CLI ( kam ) to version 0.0.41 . GITOPS-1669 This enhancement upgrades Argo CD to version 2.2.2 . GITOPS-1532 This enhancement upgrades Helm to version 3.7.1 . GITOPS-1530 This enhancement adds the health status of the DeploymentConfig , Route , and OLM Operator items to the Argo CD Dashboard and OpenShift Container Platform web console. This information helps you monitor the overall health status of your application. GITOPS-655 , GITOPS-915 , GITOPS-916 , GITOPS-1110 With this update, you can to specify the number of desired replicas for the argocd-server and argocd-repo-server components by setting the .spec.server.replicas and .spec.repo.replicas attributes in the Argo CD custom resource, respectively. If you configure the horizontal pod autoscaler (HPA) for the argocd-server components, it takes precedence over the Argo CD custom resource attributes. GITOPS-1245 As an administrative user, when you give Argo CD access to a namespace by using the argocd.argoproj.io/managed-by label, it assumes namespace-admin privileges. These privileges are an issue for administrators who provide namespaces to non-administrators, such as development teams, because the privileges enable non-administrators to modify objects such as network policies. With this update, administrators can configure a common cluster role for all the managed namespaces. In role bindings for the Argo CD application controller, the Operator refers to the CONTROLLER_CLUSTER_ROLE environment variable. In role bindings for the Argo CD server, the Operator refers to the SERVER_CLUSTER_ROLE environment variable. If these environment variables contain custom roles, the Operator doesn't create the default admin role. Instead, it uses the existing custom role for all managed namespaces. GITOPS-1290 With this update, the Environments page in the OpenShift Container Platform Developer perspective displays a broken heart icon to indicate degraded resources, excluding ones whose status is Progressing , Missing , and Unknown . The console displays a yellow yield sign icon to indicate out-of-sync resources. GITOPS-1307 5.1.35.2. Fixed issues The following issues have been resolved in the current release: Before this update, when the Route to the Red Hat OpenShift GitOps Application Manager CLI ( kam ) was accessed without specifying a path in the URL, a default page without any helpful information was displayed to the user. This update fixes the issue so that the default page displays download links for the kam CLI. GITOPS-923 Before this update, setting a resource quota in the namespace of the Argo CD custom resource might cause the setup of the Red Hat SSO (RH SSO) instance to fail. This update fixes this issue by setting a minimum resource request for the RH SSO deployment pods. GITOPS-1297 Before this update, if you changed the log level for the argocd-repo-server workload, the Operator didn't reconcile this setting. The workaround was to delete the deployment resource so that the Operator recreated it with the new log level. With this update, the log level is correctly reconciled for existing argocd-repo-server workloads. GITOPS-1387 Before this update, if the Operator managed an Argo CD instance that lacked the .data field in the argocd-secret Secret, the Operator on that instance crashed. This update fixes the issue so that the Operator doesn't crash when the .data field is missing. Instead, the secret regenerates and the gitops-operator-controller-manager resource is redeployed. GITOPS-1402 Before this update, the gitopsservice service was annotated as an internal object. This update removes the annotation so you can update or delete the default Argo CD instance and run GitOps workloads on infrastructure nodes by using the UI. GITOPS-1429 5.1.35.3. Known issues These are the known issues in the current release: If you migrate from the Dex authentication provider to the Keycloak provider, you might experience login issues with Keycloak. To prevent this issue, when migrating, uninstall Dex by removing the .spec.dex section from the Argo CD custom resource. Allow a few minutes for Dex to uninstall completely. Then, install Keycloak by adding .spec.sso.provider: keycloak to the Argo CD custom resource. As a workaround, uninstall Keycloak by removing .spec.sso.provider: keycloak . Then, re-install it. GITOPS-1450 , GITOPS-1331 5.1.36. Release notes for Red Hat OpenShift GitOps 1.3.7 Red Hat OpenShift GitOps 1.3.7 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support. 5.1.36.1. Fixed issues The following issue has been resolved in the current release: Before this update, a flaw was found in OpenSSL. This update fixes the issue by updating the base images to the latest version to avoid the OpenSSL flaw. (CVE-2022-0778) . Note To install the current release of Red Hat OpenShift GitOps 1.3 and receive further updates during its product life cycle, switch to the GitOps-1.3 channel. 5.1.37. Release notes for Red Hat OpenShift GitOps 1.3.6 Red Hat OpenShift GitOps 1.3.6 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support. 5.1.37.1. Fixed issues The following issues have been resolved in the current release: In Red Hat OpenShift GitOps, improper access control allows admin privilege escalation (CVE-2022-1025) . This update fixes the issue. A path traversal flaw allows leaking of out-of-bound files (CVE-2022-24731) . This update fixes the issue. A path traversal flaw and improper access control allows leaking of out-of-bound files (CVE-2022-24730) . This update fixes the issue. 5.1.38. Release notes for Red Hat OpenShift GitOps 1.3.2 Red Hat OpenShift GitOps 1.3.2 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support. 5.1.38.1. New features In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.3.2: Upgraded Argo CD to version 2.1.8 Upgraded Dex to version 2.30.0 5.1.38.2. Fixed issues The following issues have been resolved in the current release: Previously, in the OperatorHub UI under the Infrastructure Features section, when you filtered by Disconnected the Red Hat OpenShift GitOps Operator did not show in the search results, as the Operator did not have the related annotation set in its CSV file. With this update, the Disconnected Cluster annotation has been added to the Red Hat OpenShift GitOps Operator as an infrastructure feature. GITOPS-1539 When using an Namespace-scoped Argo CD instance, for example, an Argo CD instance that is not scoped to All Namepsaces in a cluster, Red Hat OpenShift GitOps dynamically maintains a list of managed namespaces. These namespaces include the argocd.argoproj.io/managed-by label. This list of namespaces is stored in a cache in Argo CD Settings Clusters "in-cluster" NAMESPACES . Before this update, if you deleted one of these namespaces, the Operator ignored that, and the namespace remained in the list. This behavior broke the CONNECTION STATE in that cluster configuration, and all sync attempts resulted in errors. For example: Argo service account does not have <random_verb> on <random_resource_type> in namespace <the_namespace_you_deleted>. This bug is fixed. GITOPS-1521 With this update, the Red Hat OpenShift GitOps Operator has been annotated with the Deep Insights capability level. GITOPS-1519 Previously, the Argo CD Operator managed the resource.exclusion field by itself but ignored the resource.inclusion field. This prevented the resource.inclusion field configured in the Argo CD CR to generate in the argocd-cm configuration map. This bug is fixed. GITOPS-1518 5.1.39. Release notes for Red Hat OpenShift GitOps 1.3.1 Red Hat OpenShift GitOps 1.3.1 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support. 5.1.39.1. Fixed issues If you upgrade to v1.3.0, the Operator does not return an ordered slice of environment variables. As a result, the reconciler fails causing the frequent recreation of Argo CD pods in OpenShift Container Platform clusters running behind a proxy. This update fixes the issue so that Argo CD pods are not recreated. GITOPS-1489 5.1.40. Release notes for Red Hat OpenShift GitOps 1.3 Red Hat OpenShift GitOps 1.3 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support. 5.1.40.1. New features In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.3.0: For a fresh install of v1.3.0, Dex is automatically configured. You can log into the default Argo CD instance in the openshift-gitops namespace using the OpenShift or kubeadmin credentials. As an admin you can disable the Dex installation after the Operator is installed which will remove the Dex deployment from the openshift-gitops namespace. The default Argo CD instance installed by the Operator as well as accompanying controllers can now run on the infrastructure nodes of the cluster by setting a simple configuration toggle. Internal communications in Argo CD can now be secured using the TLS and the OpenShift cluster certificates. The Argo CD routes can now leverage the OpenShift cluster certificates in addition to using external certificate managers such as the cert-manager. Use the improved Environments page in the Developer perspective of the console 4.9 to gain insights into the GitOps environments. You can now access custom health checks in Argo CD for DeploymentConfig resources, Route resources, and Operators installed using OLM. The GitOps Operator now conforms to the naming conventions recommended by the latest Operator-SDK: The prefix gitops-operator- is added to all resources Service account is renamed to gitops-operator-controller-manager 5.1.40.2. Fixed issues The following issues were resolved in the current release: Previously, if you set up a new namespace to be managed by a new instance of Argo CD, it would immediately be Out Of Sync due to the new roles and bindings that the Operator creates to manage that new namespace. This behavior is fixed. GITOPS-1384 5.1.40.3. Known issues While migrating from the Dex authentication provider to the Keycloak provider, you may experience login issues with Keycloak. GITOPS-1450 To prevent the above issue, when migrating, uninstall Dex by removing the .spec.dex section found in the Argo CD custom resource. Allow a few minutes for Dex to uninstall completely, and then proceed to install Keycloak by adding .spec.sso.provider: keycloak to the Argo CD custom resource. As a workaround, uninstall Keycloak by removing .spec.sso.provider: keycloak and then re-install. 5.1.41. Release notes for Red Hat OpenShift GitOps 1.2.2 Red Hat OpenShift GitOps 1.2.2 is now available on OpenShift Container Platform 4.8. 5.1.41.1. Fixed issues The following issue was resolved in the current release: All versions of Argo CD are vulnerable to a path traversal bug that allows to pass arbitrary values to be consumed by Helm charts. This update fixes the CVE-2022-24348 gitops error, path traversal and dereference of symlinks when passing Helm value files. GITOPS-1756 5.1.42. Release notes for Red Hat OpenShift GitOps 1.2.1 Red Hat OpenShift GitOps 1.2.1 is now available on OpenShift Container Platform 4.8. 5.1.42.1. Support matrix Some features in this release are currently in Technology Preview. These experimental features are not intended for production use. Technology Preview Features Support Scope In the table below, features are marked with the following statuses: TP : Technology Preview GA : General Availability Note the following scope of support on the Red Hat Customer Portal for these features: Table 5.2. Support matrix Feature Red Hat OpenShift GitOps 1.2.1 Argo CD GA Argo CD ApplicationSet TP Red Hat OpenShift GitOps Application Manager CLI ( kam ) TP 5.1.42.2. Fixed issues The following issues were resolved in the current release: Previously, huge memory spikes were observed on the application controller on startup. The flag --kubectl-parallelism-limit for the application controller is now set to 10 by default, however this value can be overridden by specifying a number for .spec.controller.kubeParallelismLimit in the Argo CD CR specification. GITOPS-1255 The latest Triggers APIs caused Kubernetes build failure due to duplicate entries in the kustomization.yaml when using the kam bootstrap command. The Pipelines and Tekton triggers components have now been updated to v0.24.2 and v0.14.2, respectively, to address this issue. GITOPS-1273 Persisting RBAC roles and bindings are now automatically removed from the target namespace when the Argo CD instance from the source namespace is deleted. GITOPS-1228 Previously, when deploying an Argo CD instance into a namespace, the Argo CD instance would change the "managed-by" label to be its own namespace. This fix would make namespaces unlabelled while also making sure the required RBAC roles and bindings are created and deleted for the namespace. GITOPS-1247 Previously, the default resource request limits on Argo CD workloads, specifically for the repo-server and application controller, were found to be very restrictive. The existing resource quota has now been removed and the default memory limit has been increased to 1024M in the repo server. Please note that this change will only affect new installations; existing Argo CD instance workloads will not be affected. GITOPS-1274 5.1.43. Release notes for Red Hat OpenShift GitOps 1.2 Red Hat OpenShift GitOps 1.2 is now available on OpenShift Container Platform 4.8. 5.1.43.1. Support matrix Some features in this release are currently in Technology Preview. These experimental features are not intended for production use. Technology Preview Features Support Scope In the table below, features are marked with the following statuses: TP : Technology Preview GA : General Availability Note the following scope of support on the Red Hat Customer Portal for these features: Table 5.3. Support matrix Feature Red Hat OpenShift GitOps 1.2 Argo CD GA Argo CD ApplicationSet TP Red Hat OpenShift GitOps Application Manager CLI ( kam ) TP 5.1.43.2. New features In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.2: If you do not have read or write access to the openshift-gitops namespace, you can now use the DISABLE_DEFAULT_ARGOCD_INSTANCE environment variable in the GitOps Operator and set the value to TRUE to prevent the default Argo CD instance from starting in the openshift-gitops namespace. Resource requests and limits are now configured in Argo CD workloads. Resource quota is enabled in the openshift-gitops namespace. As a result, out-of-band workloads deployed manually in the openshift-gitops namespace must be configured with resource requests and limits and the resource quota may need to be increased. Argo CD authentication is now integrated with Red Hat SSO and it is automatically configured with OpenShift 4 Identity Provider on the cluster. This feature is disabled by default. To enable Red Hat SSO, add SSO configuration in ArgoCD CR as shown below. Currently, keycloak is the only supported provider. apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak server: route: enabled: true You can now define hostnames using route labels to support router sharding. Support for setting labels on the server (argocd server), grafana , and prometheus routes is now available. To set labels on a route, add labels under the route configuration for a server in the ArgoCD CR. Example ArgoCD CR YAML to set labels on argocd server apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: server: route: enabled: true labels: key1: value1 key2: value2 The GitOps Operator now automatically grants permissions to Argo CD instances to manage resources in target namespaces by applying labels. Users can label the target namespace with the label argocd.argoproj.io/managed-by: <source-namespace> , where the source-namespace is the namespace where the argocd instance is deployed. 5.1.43.3. Fixed issues The following issues were resolved in the current release: Previously, if a user created additional instances of Argo CD managed by the default cluster instance in the openshift-gitops namespace, the application responsible for the new Argo CD instance would get stuck in an OutOfSync status. This issue has now been resolved by adding an owner reference to the cluster secret. GITOPS-1025 5.1.43.4. Known issues These are the known issues in Red Hat OpenShift GitOps 1.2: When an Argo CD instance is deleted from the source namespace, the argocd.argoproj.io/managed-by labels in the target namespaces are not removed. GITOPS-1228 Resource quota has been enabled in the openshift-gitops namespace in Red Hat OpenShift GitOps 1.2. This can affect out-of-band workloads deployed manually and workloads deployed by the default Argo CD instance in the openshift-gitops namespace. When you upgrade from Red Hat OpenShift GitOps v1.1.2 to v1.2 such workloads must be configured with resource requests and limits. If there are any additional workloads, the resource quota in the openshift-gitops namespace must be increased. Current Resource Quota for openshift-gitops namespace. Resource Requests Limits CPU 6688m 13750m Memory 4544Mi 9070Mi You can use the below command to update the CPU limits. USD oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]' You can use the below command to update the CPU requests. USD oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}] You can replace the path in the above commands from cpu to memory to update the memory. 5.1.44. Release notes for Red Hat OpenShift GitOps 1.1 Red Hat OpenShift GitOps 1.1 is now available on OpenShift Container Platform 4.7. 5.1.44.1. Support matrix Some features in this release are currently in Technology Preview. These experimental features are not intended for production use. Technology Preview Features Support Scope In the table below, features are marked with the following statuses: TP : Technology Preview GA : General Availability Note the following scope of support on the Red Hat Customer Portal for these features: Table 5.4. Support matrix Feature Red Hat OpenShift GitOps 1.1 Argo CD GA Argo CD ApplicationSet TP Red Hat OpenShift GitOps Application Manager CLI ( kam ) TP 5.1.44.2. New features In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.1: The ApplicationSet feature is now added (Technology Preview). The ApplicationSet feature enables both automation and greater flexibility when managing Argo CD applications across a large number of clusters and within monorepos. It also makes self-service usage possible on multitenant Kubernetes clusters. Argo CD is now integrated with cluster logging stack and with the OpenShift Container Platform Monitoring and Alerting features. Argo CD auth is now integrated with OpenShift Container Platform. Argo CD applications controller now supports horizontal scaling. Argo CD Redis servers now support high availability (HA). 5.1.44.3. Fixed issues The following issues were resolved in the current release: Previously, Red Hat OpenShift GitOps did not work as expected in a proxy server setup with active global proxy settings. This issue is fixed and now Argo CD is configured by the Red Hat OpenShift GitOps Operator using fully qualified domain names (FQDN) for the pods to enable communication between components. GITOPS-703 The Red Hat OpenShift GitOps backend relies on the ?ref= query parameter in the Red Hat OpenShift GitOps URL to make API calls. Previously, this parameter was not read from the URL, causing the backend to always consider the default reference. This issue is fixed and the Red Hat OpenShift GitOps backend now extracts the reference query parameter from the Red Hat OpenShift GitOps URL and only uses the default reference when there is no input reference provided. GITOPS-817 Previously, the Red Hat OpenShift GitOps backend failed to find the valid GitLab repository. This was because the Red Hat OpenShift GitOps backend checked for main as the branch reference, instead of master in the GitLab repository. This issue is fixed now. GITOPS-768 The Environments page in the Developer perspective of the OpenShift Container Platform web console now shows the list of applications and the number of environments. This page also displays an Argo CD link that directs you to the Argo CD Applications page that lists all the applications. The Argo CD Applications page has LABELS (for example, app.kubernetes.io/name=appName ) that help you filter only the applications of your choice. GITOPS-544 5.1.44.4. Known issues These are the known issues in Red Hat OpenShift GitOps 1.1: Red Hat OpenShift GitOps does not support Helm v2 and ksonnet. The Red Hat SSO (RH SSO) Operator is not supported in disconnected clusters. As a result, the Red Hat OpenShift GitOps Operator and RH SSO integration is not supported in disconnected clusters. When you delete an Argo CD application from the OpenShift Container Platform web console, the Argo CD application gets deleted in the user interface, but the deployments are still present in the cluster. As a workaround, delete the Argo CD application from the Argo CD console. GITOPS-830 5.1.44.5. Breaking Change 5.1.44.5.1. Upgrading from Red Hat OpenShift GitOps v1.0.1 When you upgrade from Red Hat OpenShift GitOps v1.0.1 to v1.1 , the Red Hat OpenShift GitOps Operator renames the default Argo CD instance created in the openshift-gitops namespace from argocd-cluster to openshift-gitops . This is a breaking change and needs the following steps to be performed manually, before the upgrade: Go to the OpenShift Container Platform web console and copy the content of the argocd-cm.yml config map file in the openshift-gitops namespace to a local file. The content may look like the following example: Example argocd config map YAML kind: ConfigMap apiVersion: v1 metadata: selfLink: /api/v1/namespaces/openshift-gitops/configmaps/argocd-cm resourceVersion: '112532' name: argocd-cm uid: f5226fbc-883d-47db-8b53-b5e363f007af creationTimestamp: '2021-04-16T19:24:08Z' managedFields: ... namespace: openshift-gitops labels: app.kubernetes.io/managed-by: argocd-cluster app.kubernetes.io/name: argocd-cm app.kubernetes.io/part-of: argocd data: "" 1 admin.enabled: 'true' statusbadge.enabled: 'false' resource.exclusions: | - apiGroups: - tekton.dev clusters: - '*' kinds: - TaskRun - PipelineRun ga.trackingid: '' repositories: | - type: git url: https://github.com/user-name/argocd-example-apps ga.anonymizeusers: 'false' help.chatUrl: '' url: >- https://argocd-cluster-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com "" 2 help.chatText: '' kustomize.buildOptions: '' resource.inclusions: '' repository.credentials: '' users.anonymous.enabled: 'false' configManagementPlugins: '' application.instanceLabelKey: '' 1 Restore only the data section of the content in the argocd-cm.yml config map file manually. 2 Replace the URL value in the config map entry with the new instance name openshift-gitops . Delete the default argocd-cluster instance. Edit the new argocd-cm.yml config map file to restore the entire data section manually. Replace the URL value in the config map entry with the new instance name openshift-gitops . For example, in the preceding example, replace the URL value with the following URL value: url: >- https://openshift-gitops-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com Login to the Argo CD cluster and verify that the configurations are present. 5.2. Understanding OpenShift GitOps 5.2.1. About GitOps GitOps is a declarative way to implement continuous deployment for cloud native applications. You can use GitOps to create repeatable processes for managing OpenShift Container Platform clusters and applications across multi-cluster Kubernetes environments. GitOps handles and automates complex deployments at a fast pace, saving time during deployment and release cycles. The GitOps workflow pushes an application through development, testing, staging, and production. GitOps either deploys a new application or updates an existing one, so you only need to update the repository; GitOps automates everything else. GitOps is a set of practices that use Git pull requests to manage infrastructure and application configurations. In GitOps, the Git repository is the only source of truth for system and application configuration. This Git repository contains a declarative description of the infrastructure you need in your specified environment and contains an automated process to make your environment match the described state. Also, it contains the entire state of the system so that the trail of changes to the system state are visible and auditable. By using GitOps, you resolve the issues of infrastructure and application configuration sprawl. GitOps defines infrastructure and application definitions as code. Then, it uses this code to manage multiple workspaces and clusters to simplify the creation of infrastructure and application configurations. By following the principles of the code, you can store the configuration of clusters and applications in Git repositories, and then follow the Git workflow to apply these repositories to your chosen clusters. You can apply the core principles of developing and maintaining software in a Git repository to the creation and management of your cluster and application configuration files. 5.2.2. About Red Hat OpenShift GitOps Red Hat OpenShift GitOps ensures consistency in applications when you deploy them to different clusters in different environments, such as: development, staging, and production. Red Hat OpenShift GitOps organizes the deployment process around the configuration repositories and makes them the central element. It always has at least two repositories: Application repository with the source code Environment configuration repository that defines the desired state of the application These repositories contain a declarative description of the infrastructure you need in your specified environment. They also contain an automated process to make your environment match the described state. Red Hat OpenShift GitOps uses Argo CD to maintain cluster resources. Argo CD is an open-source declarative tool for the continuous integration and continuous deployment (CI/CD) of applications. Red Hat OpenShift GitOps implements Argo CD as a controller so that it continuously monitors application definitions and configurations defined in a Git repository. Then, Argo CD compares the specified state of these configurations with their live state on the cluster. Argo CD reports any configurations that deviate from their specified state. These reports allow administrators to automatically or manually resync configurations to the defined state. Therefore, Argo CD enables you to deliver global custom resources, like the resources that are used to configure OpenShift Container Platform clusters. 5.2.2.1. Key features Red Hat OpenShift GitOps helps you automate the following tasks: Ensure that the clusters have similar states for configuration, monitoring, and storage Apply or revert configuration changes to multiple OpenShift Container Platform clusters Associate templated configuration with different environments Promote applications across clusters, from staging to production 5.3. Installing Red Hat OpenShift GitOps Red Hat OpenShift GitOps uses Argo CD to manage specific cluster-scoped resources, including cluster Operators, optional Operator Lifecycle Manager (OLM) Operators, and user management. This guide explains how to install the Red Hat OpenShift GitOps Operator to an OpenShift Container Platform cluster and log in to the Argo CD instance. Important The latest channel enables installation of the most recent stable version of the Red Hat OpenShift GitOps Operator. Currently, it is the default channel for installing the Red Hat OpenShift GitOps Operator. To install a specific version of the Red Hat OpenShift GitOps Operator, cluster administrators can use the corresponding gitops-<version> channel. For example, to install the Red Hat OpenShift GitOps Operator version 1.8.x, you can use the gitops-1.8 channel. 5.3.1. Installing Red Hat OpenShift GitOps Operator in web console Prerequisites Access to the OpenShift Container Platform web console. An account with the cluster-admin role. You are logged in to the OpenShift Container Platform cluster as an administrator. Warning If you have already installed the Community version of the Argo CD Operator, remove the Argo CD Community Operator before you install the Red Hat OpenShift GitOps Operator. Procedure Open the Administrator perspective of the web console and navigate to Operators OperatorHub in the menu on the left. Search for OpenShift GitOps , click the Red Hat OpenShift GitOps tile, and then click Install . Red Hat OpenShift GitOps will be installed in all namespaces of the cluster. After the Red Hat OpenShift GitOps Operator is installed, it automatically sets up a ready-to-use Argo CD instance that is available in the openshift-gitops namespace, and an Argo CD icon is displayed in the console toolbar. You can create subsequent Argo CD instances for your applications under your projects. 5.3.2. Installing Red Hat OpenShift GitOps Operator using CLI You can install Red Hat OpenShift GitOps Operator from the OperatorHub using the CLI. Procedure Create a Subscription object YAML file to subscribe a namespace to the Red Hat OpenShift GitOps, for example, sub.yaml : Example Subscription apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator namespace: openshift-operators spec: channel: latest 1 installPlanApproval: Automatic name: openshift-gitops-operator 2 source: redhat-operators 3 sourceNamespace: openshift-marketplace 4 1 Specify the channel name from where you want to subscribe the Operator. 2 Specify the name of the Operator to subscribe to. 3 Specify the name of the CatalogSource that provides the Operator. 4 The namespace of the CatalogSource. Use openshift-marketplace for the default OperatorHub CatalogSources. Apply the Subscription to the cluster: USD oc apply -f openshift-gitops-sub.yaml After the installation is complete, ensure that all the pods in the openshift-gitops namespace are running: USD oc get pods -n openshift-gitops Example output NAME READY STATUS RESTARTS AGE cluster-b5798d6f9-zr576 1/1 Running 0 65m kam-69866d7c48-8nsjv 1/1 Running 0 65m openshift-gitops-application-controller-0 1/1 Running 0 53m openshift-gitops-applicationset-controller-6447b8dfdd-5ckgh 1/1 Running 0 65m openshift-gitops-redis-74bd8d7d96-49bjf 1/1 Running 0 65m openshift-gitops-repo-server-c999f75d5-l4rsg 1/1 Running 0 65m openshift-gitops-server-5785f7668b-wj57t 1/1 Running 0 53m 5.3.3. Logging in to the Argo CD instance by using the Argo CD admin account Red Hat OpenShift GitOps Operator automatically creates a ready-to-use Argo CD instance that is available in the openshift-gitops namespace. Prerequisites You have installed the Red Hat OpenShift GitOps Operator in your cluster. Procedure In the Administrator perspective of the web console, navigate to Operators Installed Operators to verify that the Red Hat OpenShift GitOps Operator is installed. Navigate to the menu OpenShift GitOps Cluster Argo CD . The login page of the Argo CD UI is displayed in a new window. Optional: To log in with your OpenShift Container Platform credentials, ensure you are a user of the cluster-admins group and then select the LOG IN VIA OPENSHIFT option in the Argo CD user interface. Note To be a user of the cluster-admins group, use the oc adm groups new cluster-admins <user> command, where <user> is the default cluster role that you can bind to users and groups cluster-wide or locally. To log in with your username and password, obtain the password for the Argo CD instance: In the left panel of the console, use the perspective switcher to switch to the Developer perspective. Use the Project drop-down list and select the openshift-gitops project. Use the left navigation panel to navigate to the Secrets page. Select the openshift-gitops-cluster instance to display the password. Copy the password. Use this password and admin as the username to log in to the Argo CD UI in the new window. Note You cannot create two Argo CD CRs in the same namespace. 5.4. Uninstalling OpenShift GitOps Uninstalling the Red Hat OpenShift GitOps Operator is a two-step process: Delete the Argo CD instances that were added under the default namespace of the Red Hat OpenShift GitOps Operator. Uninstall the Red Hat OpenShift GitOps Operator. Uninstalling only the Operator will not remove the Argo CD instances created. 5.4.1. Deleting the Argo CD instances Delete the Argo CD instances added to the namespace of the GitOps Operator. Procedure In the Terminal type the following command: USD oc delete gitopsservice cluster -n openshift-gitops Note You cannot delete an Argo CD cluster from the web console UI. After the command runs successfully all the Argo CD instances will be deleted from the openshift-gitops namespace. Delete any other Argo CD instances from other namespaces using the same command: USD oc delete gitopsservice cluster -n <namespace> 5.4.2. Uninstalling the GitOps Operator Procedure From the Operators OperatorHub page, use the Filter by keyword box to search for Red Hat OpenShift GitOps Operator tile. Click the Red Hat OpenShift GitOps Operator tile. The Operator tile indicates it is installed. In the Red Hat OpenShift GitOps Operator descriptor page, click Uninstall . Additional resources You can learn more about uninstalling Operators on OpenShift Container Platform in the Deleting Operators from a cluster section. 5.5. Setting up an Argo CD instance By default, the Red Hat OpenShift GitOps installs an instance of Argo CD in the openshift-gitops namespace with additional permissions for managing certain cluster-scoped resources. To manage cluster configurations or deploy applications, you can install and deploy a new Argo CD instance. By default, any new instance has permissions to manage resources only in the namespace where it is deployed. 5.5.1. Installing Argo CD To manage cluster configurations or deploy applications, you can install and deploy a new Argo CD instance. Procedure Log in to the OpenShift Container Platform web console. Click Operators Installed Operators . Create or select the project where you want to install the Argo CD instance from the Project drop-down menu. Select OpenShift GitOps Operator from the installed operators and select the Argo CD tab. Click Create to configure the parameters: Enter the Name of the instance. By default, the Name is set to argocd . Create an external OS Route to access Argo CD server. Click Server Route and check Enabled . To open the Argo CD web UI, click the route by navigating to Networking Routes <instance name>-server in the project where the Argo CD instance is installed. 5.5.2. Enabling replicas for Argo CD server and repo server Argo CD-server and Argo CD-repo-server workloads are stateless. To better distribute your workloads among pods, you can increase the number of Argo CD-server and Argo CD-repo-server replicas. However, if a horizontal autoscaler is enabled on the Argo CD-server, it overrides the number of replicas you set. Procedure Set the replicas parameters for the repo and server spec to the number of replicas you want to run: Example Argo CD custom resource apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: repo: replicas: <number_of_replicas> server: replicas: <number_of_replicas> route: enabled: true path: / tls: insecureEdgeTerminationPolicy: Redirect termination: passthrough wildcardPolicy: None 5.5.3. Deploying resources to a different namespace To allow Argo CD to manage resources in other namespaces apart from where it is installed, configure the target namespace with a argocd.argoproj.io/managed-by label. Procedure Configure the namespace: USD oc label namespace <namespace> \ argocd.argoproj.io/managed-by=<instance_name> 1 1 The namespace where Argo CD is installed. 5.5.4. Customizing the Argo CD console link In a multi-tenant cluster, users might have to deal with multiple instances of Argo CD. For example, after installing an Argo CD instance in your namespace, you might find a different Argo CD instance attached to the Argo CD console link, instead of your own Argo CD instance, in the Console Application Launcher. You can customize the Argo CD console link by setting the DISABLE_DEFAULT_ARGOCD_CONSOLELINK environment variable: When you set DISABLE_DEFAULT_ARGOCD_CONSOLELINK to true , the Argo CD console link is permanently deleted. When you set DISABLE_DEFAULT_ARGOCD_CONSOLELINK to false or use the default value, the Argo CD console link is temporarily deleted and visible again when the Argo CD route is reconciled. Prerequisites You have logged in to the OpenShift Container Platform cluster as an administrator. You have installed the Red Hat OpenShift GitOps Operator. Procedure In the Administrator perspective, navigate to Administration CustomResourceDefinitions . Find the Subscription CRD and click to open it. Select the Instances tab and click the openshift-gitops-operator subscription. Select the YAML tab and make your customization: To enable or disable the Argo CD console link, edit the value of DISABLE_DEFAULT_ARGOCD_CONSOLELINK as needed: apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator spec: config: env: - name: DISABLE_DEFAULT_ARGOCD_CONSOLELINK value: 'true' 5.6. Monitoring Argo CD instances By default, the Red Hat OpenShift GitOps Operator automatically detects an installed Argo CD instance in your defined namespace, for example, openshift-gitops , and connects it to the monitoring stack of the cluster to provide alerts for out-of-sync applications. Prerequisites You have access to the cluster with cluster-admin privileges. You have access to the OpenShift Container Platform web console. You have installed the Red Hat OpenShift GitOps Operator in your cluster. You have installed an Argo CD application in your defined namespace, for example, openshift-gitops . 5.6.1. Monitoring Argo CD health using Prometheus metrics You can monitor the health status of an Argo CD application by running Prometheus metrics queries against it. Procedure In the Developer perspective of the web console, select the namespace where your Argo CD application is installed, and navigate to Observe Metrics . From the Select query drop-down list, select Custom query . To check the health status of your Argo CD application, enter the Prometheus Query Language (PromQL) query similar to the following example in the Expression field: Example sum(argocd_app_info{dest_namespace=~"<your_defined_namespace>",health_status!=""}) by (health_status) 1 1 Replace the <your_defined_namespace> variable with the actual name of your defined namespace, for example openshift-gitops . 5.7. Configuring an OpenShift cluster by deploying an application with cluster configurations With Red Hat OpenShift GitOps, you can configure Argo CD to recursively sync the content of a Git directory with an application that contains custom configurations for your cluster. Prerequisites You have logged in to the OpenShift Container Platform cluster as an administrator. You have installed the Red Hat OpenShift GitOps Operator in your cluster. You have logged into Argo CD instance. 5.7.1. Using an Argo CD instance to manage cluster-scoped resources To manage cluster-scoped resources, update the existing Subscription object for the Red Hat OpenShift GitOps Operator and add the namespace of the Argo CD instance to the ARGOCD_CLUSTER_CONFIG_NAMESPACES environment variable in the spec section. Procedure In the Administrator perspective of the web console, navigate to Operators Installed Operators Red Hat OpenShift GitOps Subscription . Click the Actions drop-down menu then click Edit Subscription . On the openshift-gitops-operator Subscription details page, under the YAML tab, edit the Subscription YAML file by adding the namespace of the Argo CD instance to the ARGOCD_CLUSTER_CONFIG_NAMESPACES environment variable in the spec section: apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator namespace: openshift-operators ... spec: config: env: - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES value: openshift-gitops, <list of namespaces of cluster-scoped Argo CD instances> ... To verify that the Argo instance is configured with a cluster role to manage cluster-scoped resources, perform the following steps: Navigate to User Management Roles and from the Filter drop-down menu select Cluster-wide Roles . Search for the argocd-application-controller by using the Search by name field. The Roles page displays the created cluster role. Tip Alternatively, in the OpenShift CLI, run the following command: oc auth can-i create oauth -n openshift-gitops --as system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller The output yes verifies that the Argo instance is configured with a cluster role to manage cluster-scoped resources. Else, check your configurations and take necessary steps as required. 5.7.2. Default permissions of an Argocd instance By default Argo CD instance has the following permissions: Argo CD instance has the admin privileges to manage resources only in the namespace where it is deployed. For instance, an Argo CD instance deployed in the foo namespace has the admin privileges to manage resources only for that namespace. Argo CD has the following cluster-scoped permissions because Argo CD requires cluster-wide read privileges on resources to function appropriately: - verbs: - get - list - watch apiGroups: - '*' resources: - '*' - verbs: - get - list nonResourceURLs: - '*' Note You can edit the cluster roles used by the argocd-server and argocd-application-controller components where Argo CD is running such that the write privileges are limited to only the namespaces and resources that you wish Argo CD to manage. USD oc edit clusterrole argocd-server USD oc edit clusterrole argocd-application-controller 5.7.3. Running the Argo CD instance at the cluster-level The default Argo CD instance and the accompanying controllers, installed by the Red Hat OpenShift GitOps Operator, can now run on the infrastructure nodes of the cluster by setting a simple configuration toggle. Procedure Label the existing nodes: USD oc label node <node-name> node-role.kubernetes.io/infra="" Optional: If required, you can also apply taints and isolate the workloads on infrastructure nodes and prevent other workloads from scheduling on these nodes: USD oc adm taint nodes -l node-role.kubernetes.io/infra \ infra=reserved:NoSchedule infra=reserved:NoExecute Add the runOnInfra toggle in the GitOpsService custom resource: apiVersion: pipelines.openshift.io/v1alpha1 kind: GitopsService metadata: name: cluster spec: runOnInfra: true Optional: If taints have been added to the nodes, then add tolerations to the GitOpsService custom resource, for example: spec: runOnInfra: true tolerations: - effect: NoSchedule key: infra value: reserved - effect: NoExecute key: infra value: reserved Verify that the workloads in the openshift-gitops namespace are now scheduled on the infrastructure nodes by viewing Pods Pod details for any pod in the console UI. Note Any nodeSelectors and tolerations manually added to the default Argo CD custom resource are overwritten by the toggle and tolerations in the GitOpsService custom resource. Additional resources To learn more about taints and tolerations, see Controlling pod placement using node taints . For more information on infrastructure machine sets, see Creating infrastructure machine sets . 5.7.4. Creating an application by using the Argo CD dashboard Argo CD provides a dashboard which allows you to create applications. This sample workflow walks you through the process of configuring Argo CD to recursively sync the content of the cluster directory to the cluster-configs application. The directory defines the OpenShift Container Platform web console cluster configurations that add a link to the Red Hat Developer Blog - Kubernetes under the menu in the web console, and defines a namespace spring-petclinic on the cluster. Procedure In the Argo CD dashboard, click NEW APP to add a new Argo CD application. For this workflow, create a cluster-configs application with the following configurations: Application Name cluster-configs Project default Sync Policy Manual Repository URL https://github.com/redhat-developer/openshift-gitops-getting-started Revision HEAD Path cluster Destination https://kubernetes.default.svc Namespace spring-petclinic Directory Recurse checked Click CREATE to create your application. Open the Administrator perspective of the web console and navigate to Administration Namespaces in the menu on the left. Search for and select the namespace, then enter argocd.argoproj.io/managed-by=openshift-gitops in the Label field so that the Argo CD instance in the openshift-gitops namespace can manage your namespace. 5.7.5. Creating an application by using the oc tool You can create Argo CD applications in your terminal by using the oc tool. Procedure Download the sample application : USD git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git Create the application: USD oc create -f openshift-gitops-getting-started/argo/app.yaml Run the oc get command to review the created application: USD oc get application -n openshift-gitops Add a label to the namespace your application is deployed in so that the Argo CD instance in the openshift-gitops namespace can manage it: USD oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops 5.7.6. Synchronizing your application with your Git repository Procedure In the Argo CD dashboard, notice that the cluster-configs Argo CD application has the statuses Missing and OutOfSync . Because the application was configured with a manual sync policy, Argo CD does not sync it automatically. Click SYNC on the cluster-configs tile, review the changes, and then click SYNCHRONIZE . Argo CD will detect any changes in the Git repository automatically. If the configurations are changed, Argo CD will change the status of the cluster-configs to OutOfSync . You can modify the synchronization policy for Argo CD to automatically apply changes from your Git repository to the cluster. Notice that the cluster-configs Argo CD application now has the statuses Healthy and Synced . Click the cluster-configs tile to check the details of the synchronized resources and their status on the cluster. Navigate to the OpenShift Container Platform web console and click to verify that a link to the Red Hat Developer Blog - Kubernetes is now present there. Navigate to the Project page and search for the spring-petclinic namespace to verify that it has been added to the cluster. Your cluster configurations have been successfully synchronized to the cluster. 5.7.7. In-built permissions for cluster configuration By default, the Argo CD instance has permissions to manage specific cluster-scoped resources such as cluster Operators, optional OLM Operators and user management. Note Argo CD does not have cluster-admin permissions. Permissions for the Argo CD instance: Resources Descriptions Resource Groups Configure the user or administrator operators.coreos.com Optional Operators managed by OLM user.openshift.io , rbac.authorization.k8s.io Groups, Users and their permissions config.openshift.io Control plane Operators managed by CVO used to configure cluster-wide build configuration, registry configuration and scheduler policies storage.k8s.io Storage console.openshift.io Console customization 5.7.8. Adding permissions for cluster configuration You can grant permissions for an Argo CD instance to manage cluster configuration. Create a cluster role with additional permissions and then create a new cluster role binding to associate the cluster role with a service account. Procedure Log in to the OpenShift Container Platform web console as an admin. In the web console, select User Management Roles Create Role . Use the following ClusterRole YAML template to add rules to specify the additional permissions. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secrets-cluster-role rules: - apiGroups: [""] resources: ["secrets"] verbs: ["*"] Click Create to add the cluster role. Now create the cluster role binding. In the web console, select User Management Role Bindings Create Binding . Select All Projects from the Project drop-down. Click Create binding . Select Binding type as Cluster-wide role binding (ClusterRoleBinding) . Enter a unique value for the RoleBinding name . Select the newly created cluster role or an existing cluster role from the drop down list. Select the Subject as ServiceAccount and the provide the Subject namespace and name . Subject namespace : openshift-gitops Subject name : openshift-gitops-argocd-application-controller Click Create . The YAML file for the ClusterRoleBinding object is as follows: kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: cluster-role-binding subjects: - kind: ServiceAccount name: openshift-gitops-argocd-application-controller namespace: openshift-gitops roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin 5.7.9. Installing OLM Operators using Red Hat OpenShift GitOps Red Hat OpenShift GitOps with cluster configurations manages specific cluster-scoped resources and takes care of installing cluster Operators or any namespace-scoped OLM Operators. Consider a case where as a cluster administrator, you have to install an OLM Operator such as Tekton. You use the OpenShift Container Platform web console to manually install a Tekton Operator or the OpenShift CLI to manually install a Tekton subscription and Tekton Operator group on your cluster. Red Hat OpenShift GitOps places your Kubernetes resources in your Git repository. As a cluster administrator, use Red Hat OpenShift GitOps to manage and automate the installation of other OLM Operators without any manual procedures. For example, after you place the Tekton subscription in your Git repository by using Red Hat OpenShift GitOps, the Red Hat OpenShift GitOps automatically takes this Tekton subscription from your Git repository and installs the Tekton Operator on your cluster. 5.7.9.1. Installing cluster-scoped Operators Operator Lifecycle Manager (OLM) uses a default global-operators Operator group in the openshift-operators namespace for cluster-scoped Operators. Hence you do not have to manage the OperatorGroup resource in your Gitops repository. However, for namespace-scoped Operators, you must manage the OperatorGroup resource in that namespace. To install cluster-scoped Operators, create and place the Subscription resource of the required Operator in your Git repository. Example: Grafana Operator subscription apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: grafana spec: channel: v4 installPlanApproval: Automatic name: grafana-operator source: redhat-operators sourceNamespace: openshift-marketplace 5.7.9.2. Installing namepace-scoped Operators To install namespace-scoped Operators, create and place the Subscription and OperatorGroup resources of the required Operator in your Git repository. Example: Ansible Automation Platform Resource Operator ... apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: ansible-automation-platform ... apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ansible-automation-platform-operator namespace: ansible-automation-platform spec: targetNamespaces: - ansible-automation-platform ... apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ansible-automation-platform namespace: ansible-automation-platform spec: channel: patch-me installPlanApproval: Automatic name: ansible-automation-platform-operator source: redhat-operators sourceNamespace: openshift-marketplace ... Important When deploying multiple Operators using Red Hat OpenShift GitOps, you must create only a single Operator group in the corresponding namespace. If more than one Operator group exists in a single namespace, any CSV created in that namespace transition to a failure state with the TooManyOperatorGroups reason. After the number of Operator groups in their corresponding namespaces reaches one, all the failure state CSVs transition to pending state. You must manually approve the pending install plan to complete the Operator installation. 5.8. Deploying a Spring Boot application with Argo CD With Argo CD, you can deploy your applications to the OpenShift cluster either by using the Argo CD dashboard or by using the oc tool. Prerequisites Red Hat OpenShift GitOps is installed in your cluster. Logged into Argo CD instance. 5.8.1. Creating an application by using the Argo CD dashboard Argo CD provides a dashboard which allows you to create applications. This sample workflow walks you through the process of configuring Argo CD to recursively sync the content of the cluster directory to the cluster-configs application. The directory defines the OpenShift Container Platform web console cluster configurations that add a link to the Red Hat Developer Blog - Kubernetes under the menu in the web console, and defines a namespace spring-petclinic on the cluster. Procedure In the Argo CD dashboard, click NEW APP to add a new Argo CD application. For this workflow, create a cluster-configs application with the following configurations: Application Name cluster-configs Project default Sync Policy Manual Repository URL https://github.com/redhat-developer/openshift-gitops-getting-started Revision HEAD Path cluster Destination https://kubernetes.default.svc Namespace spring-petclinic Directory Recurse checked For this workflow, create a spring-petclinic application with the following configurations: Application Name spring-petclinic Project default Sync Policy Automatic Repository URL https://github.com/redhat-developer/openshift-gitops-getting-started Revision HEAD Path app Destination https://kubernetes.default.svc Namespace spring-petclinic Click CREATE to create your application. Open the Administrator perspective of the web console and navigate to Administration Namespaces in the menu on the left. Search for and select the namespace, then enter argocd.argoproj.io/managed-by=openshift-gitops in the Label field so that the Argo CD instance in the openshift-gitops namespace can manage your namespace. 5.8.2. Creating an application by using the oc tool You can create Argo CD applications in your terminal by using the oc tool. Procedure Download the sample application : USD git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git Create the application: USD oc create -f openshift-gitops-getting-started/argo/app.yaml USD oc create -f openshift-gitops-getting-started/argo/app.yaml Run the oc get command to review the created application: USD oc get application -n openshift-gitops Add a label to the namespace your application is deployed in so that the Argo CD instance in the openshift-gitops namespace can manage it: USD oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops USD oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops 5.8.3. Verifying Argo CD self-healing behavior Argo CD constantly monitors the state of deployed applications, detects differences between the specified manifests in Git and live changes in the cluster, and then automatically corrects them. This behavior is referred to as self-healing. You can test and observe the self-healing behavior in Argo CD. Prerequisites The sample app-spring-petclinic application is deployed and configured. Procedure In the Argo CD dashboard, verify that your application has the Synced status. Click the app-spring-petclinic tile in the Argo CD dashboard to view the application resources that are deployed to the cluster. In the OpenShift Container Platform web console, navigate to the Developer perspective. Modify the Spring PetClinic deployment and commit the changes to the app/ directory of the Git repository. Argo CD will automatically deploy the changes to the cluster. Fork the OpenShift GitOps getting started repository . In the deployment.yaml file, change the failureThreshold value to 5 . In the deployment cluster, run the following command to verify the changed value of the failureThreshold field: USD oc edit deployment spring-petclinic -n spring-petclinic Test the self-healing behavior by modifying the deployment on the cluster and scaling it up to two pods while watching the application in the OpenShift Container Platform web console. Run the following command to modify the deployment: USD oc scale deployment spring-petclinic --replicas 2 -n spring-petclinic In the OpenShift Container Platform web console, notice that the deployment scales up to two pods and immediately scales down again to one pod. Argo CD detected a difference from the Git repository and auto-healed the application on the OpenShift Container Platform cluster. In the Argo CD dashboard, click the app-spring-petclinic tile APP DETAILS EVENTS . The EVENTS tab displays the following events: Argo CD detecting out of sync deployment resources on the cluster and then resyncing the Git repository to correct it. 5.9. Argo CD Operator The ArgoCD custom resource is a Kubernetes Custom Resource (CRD) that describes the desired state for a given Argo CD cluster that allows you to configure the components which make up an Argo CD cluster. 5.9.1. Argo CD CLI tool The Argo CD CLI tool is a tool used to configure Argo CD through the command line. Red Hat OpenShift GitOps does not support this binary. Use the OpenShift Console to configure the Argo CD. 5.9.2. Argo CD custom resource properties The Argo CD Custom Resource consists of the following properties: Name Description Default Properties ApplicationInstanceLabelKey The metadata.label key name where Argo CD injects the app name as a tracking label. app.kubernetes.io/instance ApplicationSet ApplicationSet controller configuration options. <Object> <Image> - The container image for the ApplicationSet controller. This overrides the ARGOCD_APPLICATIONSET_IMAGE environment variable. <Version> - The tag to use with the ApplicationSet container image. <Resources> - The container compute resources. <LogLevel> - The log level used by the Argo CD Application Controller component. Valid options are debug , info , error , and warn . <LogFormat> - The log format used by the Argo CD Application Controller component. Valid options are text or json . <PrallelismLimit> - The kubectl parallelism limit to set for the controller (--kubectl-parallelism-limit flag) . ConfigManagementPlugins Add a configuration management plugin. <empty> Controller Argo CD Application Controller options. <Object> <Processors.Operation> - The number of operation processors. <Processors.Status> - The number of status processors. <Resources> - The container compute resources. <LogLevel> - The log level used by the Argo CD Application Controller component. Valid options are debug , info , error , and warn . <AppSync> - AppSync is used to control the sync frequency of Argo CD applications <Sharding.enabled> - Enable sharding on the Argo CD Application Controller component. This property is used to manage a large number of clusters to relieve memory pressure on the controller component. <Sharding.replicas> - The number of replicas that will be used to support sharding of the Argo CD Application Controller. <Env> - Environment to set for the application controller workloads. DisableAdmin Disables the built-in admin user. false GATrackingID Use a Google Analytics tracking ID. <empty> GAAnonymizeusers Enable hashed usernames sent to google analytics. false HA High availablity options. <Object> <Enabled> - Toggle high availability support globally for Argo CD. <RedisProxyImage> - The Redis HAProxy container image. This overrides the ARGOCD_REDIS_HA_PROXY_IMAGE environment variable. <RedisProxyVersion> - The tag to use for the Redis HAProxy container image. HelpChatURL URL for getting chat help (this will typically be your Slack channel for support). https://mycorp.slack.com/argo-cd HelpChatText The text that appears in a text box for getting chat help. Chat now! Image The container image for all Argo CD components. This overrides the ARGOCD_IMAGE environment variable. argoproj/argocd Ingress Ingress configuration options. <Object> InitialRepositories Initial Git repositories to configure Argo CD to use upon creation of the cluster. <empty> Notifications Notifications controller configuration options. <Object> <Enabled> - The toggle to start the notifications-controller. <Image> - The container image for all Argo CD components. This overrides the ARGOCD_IMAGE environment variable. <Version> - The tag to use with the Notifications container image. <Resources> - The container compute resources. <LogLevel> - The log level used by the Argo CD Application Controller component. Valid options are debug , info , error , and warn . RepositoryCredentials Git repository credential templates to configure Argo CD to use upon creation of the cluster. <empty> InitialSSHKnownHosts Initial SSH Known Hosts for Argo CD to use upon creation of the cluster. <default_Argo_CD_Known_Hosts> KustomizeBuildOptions The build options and parameters to use with kustomize build . <empty> OIDCConfig The OIDC configuration as an alternative to Dex. <empty> NodePlacement Add the nodeSelector and the tolerations . <empty> Prometheus Prometheus configuration options. <Object> <Enabled> - Toggle Prometheus support globally for Argo CD. <Host> - The hostname to use for Ingress or Route resources. <Ingress> - Toggles Ingress for Prometheus. <Route> - Route configuration options. <Size> - The replica count for the Prometheus StatefulSet . RBAC RBAC configuration options. <Object> <DefaultPolicy> - The policy.default property in the argocd-rbac-cm config map. The name of the default role which Argo CD will fall back to, when authorizing API requests. <Policy> - The policy.csv property in the argocd-rbac-cm config map. CSV data containing user-defined RBAC policies and role definitions. <Scopes> - The scopes property in the argocd-rbac-cm config map. Controls which OIDC scopes to examine during RBAC enforcement (in addition to sub scope). Redis Redis configuration options. <Object> <AutoTLS> - Use the provider to create the Redis server's TLS certificate (one of: openshift). Currently only available for OpenShift Container Platform. <DisableTLSVerification> - Define whether the Redis server should be accessed using strict TLS validation. <Image> - The container image for Redis. This overrides the ARGOCD_REDIS_IMAGE environment variable. <Resources> - The container compute resources. <Version> - The tag to use with the Redis container image. ResourceCustomizations Customize resource behavior. <empty> ResourceExclusions Completely ignore entire classes of resource group. <empty> ResourceInclusions The configuration to configure which resource group/kinds are applied. <empty> Server Argo CD Server configuration options. <Object> <Autoscale> - Server autoscale configuration options. <ExtraCommandArgs> - List of arguments added to the existing arguments set by the Operator. <GRPC> - GRPC configuration options. <Host> - The hostname used for Ingress or Route resources. <Ingress> - Ingress configuration for the Argo CD server component. <Insecure> - Toggles the insecure flag for Argo CD server. <Resources> - The container compute resources. <Replicas> - The number of replicas for the Argo CD server. Must be greater than or equal to 0 . If Autoscale is enabled, Replicas is ignored. <Route> - Route configuration options. <Service.Type> - The ServiceType used for the service resource. <LogLevel> - The log level to be used by the Argo CD Server component. Valid options are debug , info , error , and warn . <LogFormat> - The log format used by the Argo CD Application Controller component. Valid options are text or json . <Env> - Environment to set for the server workloads. SSO Single Sign-on options. <Object> <Image> - The container image for Keycloak. This overrides the ARGOCD_KEYCLOAK_IMAGE environment variable. <Keycloak> - Configuration options for Keycloak SSO provider. <Dex> - Configuration options for Dex SSO provider. <Provider> - The name of the provider used to configure Single Sign-on. For now the supported options are Dex and Keycloak. <Resources> - The container compute resources. <VerifyTLS> - Whether to enforce strict TLS checking when communicating with Keycloak service. <Version> - The tag to use with the Keycloak container image. StatusBadgeEnabled Enable application status badge. true TLS TLS configuration options. <Object> <CA.ConfigMapName> - The name of the ConfigMap which contains the CA certificate. <CA.SecretName> - The name of the secret which contains the CA Certificate and Key. <InitialCerts> - Initial set of certificates in the argocd-tls-certs-cm config map for connecting Git repositories via HTTPS. UserAnonyousEnabled Enable anonymous user access. true Version The tag to use with the container image for all Argo CD components. Latest Argo CD version Banner Add a UI banner message. <Object> <Banner.Content> - The banner message content (required if a banner is displayed). <Banner.URL.SecretName> - The banner message link URL (optional). 5.9.3. Repo server properties The following properties are available for configuring the Repo server component: Name Default Description Resources <empty> The container compute resources. MountSAToken false Whether the ServiceAccount token should be mounted to the repo-server pod. ServiceAccount "" The name of the ServiceAccount to use with the repo-server pod. VerifyTLS false Whether to enforce strict TLS checking on all components when communicating with repo server. AutoTLS "" Provider to use for setting up TLS the repo-server's gRPC TLS certificate (one of: openshift). Currently only available for OpenShift. Image argoproj/argocd The container image for Argo CD Repo server. This overrides the ARGOCD_REPOSERVER_IMAGE environment variable. Version same as .spec.Version The tag to use with the Argo CD Repo server. LogLevel info The log level used by the Argo CD Repo server. Valid options are debug, info, error, and warn. LogFormat text The log format to be used by the Argo CD Repo server. Valid options are text or json. ExecTimeout 180 Execution timeout in seconds for rendering tools (e.g. Helm, Kustomize). Env <empty> Environment to set for the repository server workloads. Replicas <empty> The number of replicas for the Argo CD Repo server. Must be greater than or equal to 0 . 5.9.4. Enabling notifications with Argo CD instance To enable or disable the Argo CD notifications controller , set a parameter in the Argo CD custom resource. By default, notifications are disabled. To enable notifications, set the enabled parameter to true in the .yaml file: Procedure Set the enabled parameter to true : apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: notifications: enabled: true 5.10. Configuring secure communication with Redis Using the Transport Layer Security (TLS) encryption with Red Hat OpenShift GitOps, you can secure the communication between the Argo CD components and Redis cache and protect the possibly sensitive data in transit. You can secure communication with Redis by using one of the following configurations: Enable the autotls setting to issue an appropriate certificate for TLS encryption. Manually configure the TLS encryption by creating the argocd-operator-redis-tls secret with a key and certificate pair. Both configurations are possible with or without the High Availability (HA) enabled. Prerequisites You have access to the cluster with cluster-admin privileges. You have access to the OpenShift Container Platform web console. Red Hat OpenShift GitOps Operator is installed on your cluster. 5.10.1. Configuring TLS for Redis with autotls enabled You can configure TLS encryption for Redis by enabling the autotls setting on a new or already existing Argo CD instance. The configuration automatically provisions the argocd-operator-redis-tls secret and does not require further steps. Currently, OpenShift Container Platform is the only supported secret provider. Note By default, the autotls setting is disabled. Procedure Log in to the OpenShift Container Platform web console. Create an Argo CD instance with autotls enabled: In the Administrator perspective of the web console, use the left navigation panel to go to Administration CustomResourceDefinitions . Search for argocds.argoproj.io and click ArgoCD custom resource definition (CRD). On the CustomResourceDefinition details page, click the Instances tab, and then click Create ArgoCD . Edit or replace the YAML similar to the following example: Example Argo CD CR with autotls enabled apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: argocd 1 namespace: openshift-gitops 2 spec: redis: autotls: openshift 3 ha: enabled: true 4 1 The name of the Argo CD instance. 2 The namespace where you want to run the Argo CD instance. 3 The flag that enables the autotls setting and creates a TLS certificate for Redis. 4 The flag value that enables the HA feature. If you do not want to enable HA, do not include this line or set the flag value as false . Tip Alternatively, you can enable the autotls setting on an already existing Argo CD instance by running the following command: USD oc patch argocds.argoproj.io <instance-name> --type=merge -p '{"spec":{"redis":{"autotls":"openshift"}}}' Click Create . Verify that the Argo CD pods are ready and running: USD oc get pods -n <namespace> 1 1 Specify a namespace where the Argo CD instance is running, for example openshift-gitops . Example output with HA disabled NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s Note The HA-enabled TLS configuration requires a cluster with at least three worker nodes. It can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration. Example output with HA enabled NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m Verify that the argocd-operator-redis-tls secret is created: USD oc get secrets argocd-operator-redis-tls -n <namespace> 1 1 Specify a namespace where the Argo CD instance is running, for example openshift-gitops . Example output NAME TYPE DATA AGE argocd-operator-redis-tls kubernetes.io/tls 2 30s The secret must be of the kubernetes.io/tls type and a size of 2 . 5.10.2. Configuring TLS for Redis with autotls disabled You can manually configure TLS encryption for Redis by creating the argocd-operator-redis-tls secret with a key and certificate pair. In addition, you must annotate the secret to indicate that it belongs to the appropriate Argo CD instance. The steps to create a certificate and secret vary for instances with High Availability (HA) enabled. Procedure Log in to the OpenShift Container Platform web console. Create an Argo CD instance: In the Administrator perspective of the web console, use the left navigation panel to go to Administration CustomResourceDefinitions . Search for argocds.argoproj.io and click ArgoCD custom resource definition (CRD). On the CustomResourceDefinition details page, click the Instances tab, and then click Create ArgoCD . Edit or replace the YAML similar to the following example: Example ArgoCD CR with autotls disabled apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: argocd 1 namespace: openshift-gitops 2 spec: ha: enabled: true 3 1 The name of the Argo CD instance. 2 The namespace where you want to run the Argo CD instance. 3 The flag value that enables the HA feature. If you do not want to enable HA, do not include this line or set the flag value as false . Click Create . Verify that the Argo CD pods are ready and running: USD oc get pods -n <namespace> 1 1 Specify a namespace where the Argo CD instance is running, for example openshift-gitops . Example output with HA disabled NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s Note The HA-enabled TLS configuration requires a cluster with at least three worker nodes. It can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration. Example output with HA enabled NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m Create a self-signed certificate for the Redis server by using one of the following options depending on your HA configuration: For the Argo CD instance with HA disabled, run the following command: USD openssl req -new -x509 -sha256 \ -subj "/C=XX/ST=XX/O=Testing/CN=redis" \ -reqexts SAN -extensions SAN \ -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1 -keyout /tmp/redis.key \ -out /tmp/redis.crt \ -newkey rsa:4096 \ -nodes \ -sha256 \ -days 10 1 Specify a namespace where the Argo CD instance is running, for example openshift-gitops . Example output Generating a RSA private key ...............++++ ............................++++ writing new private key to '/tmp/redis.key' For the Argo CD instance with HA enabled, run the following command: USD openssl req -new -x509 -sha256 \ -subj "/C=XX/ST=XX/O=Testing/CN=redis" \ -reqexts SAN -extensions SAN \ -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis-ha-haproxy.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1 -keyout /tmp/redis-ha.key \ -out /tmp/redis-ha.crt \ -newkey rsa:4096 \ -nodes \ -sha256 \ -days 10 1 Specify a namespace where the Argo CD instance is running, for example openshift-gitops . Example output Generating a RSA private key ...............++++ ............................++++ writing new private key to '/tmp/redis-ha.key' Verify that the generated certificate and key are available in the /tmp directory by running the following commands: USD cd /tmp USD ls Example output with HA disabled ... redis.crt redis.key ... Example output with HA enabled ... redis-ha.crt redis-ha.key ... Create the argocd-operator-redis-tls secret by using one of the following options depending on your HA configuration: For the Argo CD instance with HA disabled, run the following command: USD oc create secret tls argocd-operator-redis-tls --key=/tmp/redis.key --cert=/tmp/redis.crt For the Argo CD instance with HA enabled, run the following command: USD oc create secret tls argocd-operator-redis-tls --key=/tmp/redis-ha.key --cert=/tmp/redis-ha.crt Example output secret/argocd-operator-redis-tls created Annotate the secret to indicate that it belongs to the Argo CD CR: USD oc annotate secret argocd-operator-redis-tls argocds.argoproj.io/name=<instance-name> 1 1 Specify a name of the Argo CD instance, for example argocd . Example output secret/argocd-operator-redis-tls annotated Verify that the Argo CD pods are ready and running: USD oc get pods -n <namespace> 1 1 Specify a namespace where the Argo CD instance is running, for example openshift-gitops . Example output with HA disabled NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s Note It can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration. Example output with HA enabled NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m 5.11. Monitoring health information for application resources and deployments The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console shows a list of the successful deployments of the application environments, along with links to the revision for each deployment. The Application environments page in the Developer perspective of the OpenShift Container Platform web console displays the health status of the application resources, such as routes, synchronization status, deployment configuration, and deployment history. The environments pages in the Developer perspective of the OpenShift Container Platform web console are decoupled from the Red Hat OpenShift GitOps Application Manager command-line interface (CLI), kam . You do not have to use kam to generate Application Environment manifests for the environments to show up in the Developer perspective of the OpenShift Container Platform web console. You can use your own manifests, but the environments must still be represented by namespaces. In addition, specific labels and annotations are still needed. 5.11.1. Settings for environment labels and annotations This section provides reference settings for environment labels and annotations required to display an environment application in the Environments page, in the Developer perspective of the OpenShift Container Platform web console. Environment labels The environment application manifest must contain labels.openshift.gitops/environment and destination.namespace fields. You must set identical values for the <environment_name> variable and the name of the environment application manifest. Specification of the environment application manifest spec: labels: openshift.gitops/environment: <environment_name> destination: namespace: <environment_name> ... Example of an environment application manifest apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: dev-env 1 namespace: openshift-gitops spec: labels: openshift.gitops/environment: dev-env destination: namespace: dev-env ... 1 The name of the environment application manifest. The value set is the same as the value of the <environment_name> variable. Environment annotations The environment namespace manifest must contain the annotations.app.openshift.io/vcs-uri and annotations.app.openshift.io/vcs-ref fields to specify the version controller code source of the application. You must set identical values for the <environment_name> variable and the name of the environment namespace manifest. Specification of the environment namespace manifest apiVersion: v1 kind: Namespace metadata: annotations: app.openshift.io/vcs-uri: <application_source_url> app.openshift.io/vcs-ref: <branch_reference> name: <environment_name> 1 ... 1 The name of the environment namespace manifest. The value set is the same as the value of the <environment_name> variable. Example of an environment namespace manifest apiVersion: v1 kind: Namespace metadata: annotations: app.openshift.io/vcs-uri: https://example.com/<your_domain>/<your_gitops.git> app.openshift.io/vcs-ref: main labels: argocd.argoproj.io/managed-by: openshift-gitops name: dev-env ... 5.11.2. Checking health information The Red Hat OpenShift GitOps Operator will install the GitOps backend service in the openshift-gitops namespace. Prerequisites The Red Hat OpenShift GitOps Operator is installed from OperatorHub . Ensure that your applications are synchronized by Argo CD. Procedure Click Environments under the Developer perspective. The Environments page shows the list of applications along with their Environment status . Hover over the icons under the Environment status column to see the synchronization status of all the environments. Click on the application name from the list to view the details of a specific application. In the Application environments page, if the Resources section under the Overview tab displays icons, hover over the icons to get status details. A broken heart indicates that resource issues have degraded the application's performance. A yellow yield sign indicates that resource issues have delayed data about the application's health. 5.12. Configuring SSO for Argo CD using Dex After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with admin permissions. To manage multiple users, cluster administrators can use Argo CD to configure Single Sign-On (SSO). Important The spec.dex parameter in the ArgoCD CR is deprecated. In a future release of Red Hat OpenShift GitOps v1.9, configuring Dex using the spec.dex parameter in the ArgoCD CR is planned to be removed. Consider using the .spec.sso parameter instead. 5.12.1. Enabling the Dex OpenShift OAuth Connector Dex uses the users and groups defined within OpenShift by checking the OAuth server provided by the platform. The following example shows the properties of Dex along with example configurations: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: openshift-oauth spec: dex: openShiftOAuth: true 1 groups: 2 - default rbac: 3 defaultPolicy: 'role:readonly' policy: | g, cluster-admins, role:admin scopes: '[groups]' 1 The openShiftOAuth property triggers the Operator to automatically configure the built-in OpenShift OAuth server when the value is set to true . 2 The groups property allows users of the specified group(s) to log in. 3 The RBAC policy property assigns the admin role in the Argo CD cluster to users in the OpenShift cluster-admins group. 5.12.1.1. Mapping users to specific roles Argo CD cannot map users to specific roles if they have a direct ClusterRoleBinding role. You can manually change the role as role:admin on SSO through OpenShift. Procedure Create a group named cluster-admins . USD oc adm groups new cluster-admins Add the user to the group. USD oc adm groups add-users cluster-admins USER Apply the cluster-admin ClusterRole to the group: USD oc adm policy add-cluster-role-to-group cluster-admin cluster-admins 5.12.2. Disabling Dex Dex is installed by default for all the Argo CD instances created by the Operator. You can configure Red Hat OpenShift GitOps to use Dex as the SSO authentication provider by setting the .spec.dex parameter. Important In Red Hat OpenShift GitOps v1.6.0, DISABLE_DEX is deprecated and is planned to be removed in Red Hat OpenShift GitOps v1.9.0. Consider using the .spec.sso.dex parameter instead. See "Enabling or disabling Dex using .spec.sso". Procedure Set the environmental variable DISABLE_DEX to true in the YAML resource of the Operator: ... spec: config: env: - name: DISABLE_DEX value: "true" ... 5.12.3. Enabling or disabling Dex using .spec.sso You can configure Red Hat OpenShift GitOps to use Dex as its SSO authentication provider by setting the .spec.sso parameter. Procedure To enable Dex, set the .spec.sso.provider: dex parameter in the YAML resource of the Operator: ... spec: sso: provider: dex dex: openShiftOAuth: true ... To disable dex, either remove the spec.sso element from the Argo CD custom resource, or specify a different SSO provider. 5.13. Configuring SSO for Argo CD using Keycloak After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with admin permissions. To manage multiple users, cluster administrators can use Argo CD to configure Single Sign-On (SSO). Prerequisites Red Hat SSO is installed on the cluster. Red Hat OpenShift GitOps Operator is installed on the cluster. Argo CD is installed on the cluster. 5.13.1. Configuring a new client in Keycloak Dex is installed by default for all the Argo CD instances created by the Operator. However, you can delete the Dex configuration and add Keycloak instead to log in to Argo CD using your OpenShift credentials. Keycloak acts as an identity broker between Argo CD and OpenShift. Procedure To configure Keycloak, follow these steps: Delete the Dex configuration by removing the .spec.sso.dex parameter from the Argo CD custom resource (CR), and save the CR: dex: openShiftOAuth: true resources: limits: cpu: memory: requests: cpu: memory: Set the value of the provider parameter to keycloak in the Argo CD CR. Configure Keycloak by performing one of the following steps: For a secure connection, set the value of the rootCA parameter as shown in the following example: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: "<PEM-encoded-root-certificate>" 1 server: route: enabled: true 1 A custom certificate used to verify the Keycloak's TLS certificate. The Operator reconciles changes in the .spec.keycloak.rootCA parameter and updates the oidc.config parameter with the PEM encoded root certificate in the argocd-cm configuration map. For an insecure connection, leave the value of the rootCA parameter empty and use the oidc.tls.insecure.skip.verify parameter as shown below: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: extraConfig: oidc.tls.insecure.skip.verify: "true" sso: provider: keycloak keycloak: rootCA: "" Note The Keycloak instance takes 2-3 minutes to install and run. 5.13.2. Logging in to Keycloak Log in to the Keycloak console to manage identities or roles and define the permissions assigned to the various roles. Prerequisites The default configuration of Dex is removed. Your Argo CD CR must be configured to use the Keycloak SSO provider. Procedure Get the Keycloak route URL for login: USD oc -n argocd get route keycloak NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD keycloak keycloak-default.apps.ci-ln-******.origin-ci-int-aws.dev.**.com keycloak <all> reencrypt None Get the Keycloak pod name that stores the user name and password as environment variables: USD oc -n argocd get pods NAME READY STATUS RESTARTS AGE keycloak-1-2sjcl 1/1 Running 0 45m Get the Keycloak user name: USD oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_USERNAME SSO_ADMIN_USERNAME=<username> Get the Keycloak password: USD oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD SSO_ADMIN_PASSWORD=<password> On the login page, click LOG IN VIA KEYCLOAK . Note You only see the option LOGIN VIA KEYCLOAK after the Keycloak instance is ready. Click Login with OpenShift . Note Login using kubeadmin is not supported. Enter the OpenShift credentials to log in. Optional: By default, any user logged in to Argo CD has read-only access. You can manage the user level access by updating the argocd-rbac-cm config map: policy.csv: <name>, <email>, role:admin 5.13.3. Uninstalling Keycloak You can delete the Keycloak resources and their relevant configurations by removing the SSO field from the Argo CD Custom Resource (CR) file. After you remove the SSO field, the values in the file look similar to the following: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: server: route: enabled: true Note A Keycloak application created by using this method is currently not persistent. Additional configurations created in the Argo CD Keycloak realm are deleted when the server restarts. 5.14. Configuring Argo CD RBAC By default, if you are logged into Argo CD using RHSSO, you are a read-only user. You can change and manage the user level access. 5.14.1. Configuring user level access To manage and modify the user level access, configure the RBAC section in Argo CD custom resource. Procedure Edit the argocd Custom Resource: USD oc edit argocd [argocd-instance-name] -n [namespace] Output metadata ... ... rbac: policy: 'g, rbacsystem:cluster-admins, role:admin' scopes: '[groups]' Add the policy configuration to the rbac section and add the name , email and the role of the user: metadata ... ... rbac: policy: <name>, <email>, role:<admin> scopes: '[groups]' Note Currently, RHSSO cannot read the group information of Red Hat OpenShift GitOps users. Therefore, configure the RBAC at the user level. 5.14.2. Modifying RHSSO resource requests/limits By default, the RHSSO container is created with resource requests and limitations. You can change and manage the resource requests. Resource Requests Limits CPU 500 1000m Memory 512 Mi 1024 Mi Procedure Modify the default resource requirements patching the Argo CD CR: USD oc -n openshift-gitops patch argocd openshift-gitops --type='json' -p='[{"op": "add", "path": "/spec/sso", "value": {"provider": "keycloak", "resources": {"requests": {"cpu": "512m", "memory": "512Mi"}, "limits": {"cpu": "1024m", "memory": "1024Mi"}} }}]' Note RHSSO created by the Red Hat OpenShift GitOps only persists the changes that are made by the operator. If the RHSSO restarts, any additional configuration created by the Admin in RHSSO is deleted. 5.15. Configuring resource quota or requests With the Argo CD Custom Resource, you can create, update, and delete resource requests and limits for Argo CD workloads. 5.15.1. Configuring workloads with resource requests and limits You can create Argo CD custom resource workloads with resource requests and limits. This is required when you want to deploy the Argo CD instance in a namespace that is configured with resource quotas. The following Argo CD instance deploys the Argo CD workloads such as Application Controller , ApplicationSet Controller , Dex , Redis , Repo Server , and Server with resource requests and limits. You can also create the other workloads with resource requirements in the same manner. apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example spec: server: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 125m memory: 128Mi route: enabled: true applicationSet: resources: limits: cpu: '2' memory: 1Gi requests: cpu: 250m memory: 512Mi repo: resources: limits: cpu: '1' memory: 512Mi requests: cpu: 250m memory: 256Mi dex: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 250m memory: 128Mi redis: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 250m memory: 128Mi controller: resources: limits: cpu: '2' memory: 2Gi requests: cpu: 250m memory: 1Gi 5.15.2. Patching Argo CD instance to update the resource requirements You can update the resource requirements for all or any of the workloads post installation. Procedure Update the Application Controller resource requests of an Argo CD instance in the Argo CD namespace. oc -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/cpu", "value":"1"}]' oc -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/memory", "value":"512Mi"}]' 5.15.3. Removing resource requests You can also remove resource requirements for all or any of your workloads after installation. Procedure Remove the Application Controller resource requests of an Argo CD instance in the Argo CD namespace. oc -n argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/cpu"}]' oc -n argocd argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/memory"}]' 5.16. Monitoring Argo CD custom resource workloads With Red Hat OpenShift GitOps, you can monitor the availability of Argo CD custom resource workloads for specific Argo CD instances. By monitoring Argo CD custom resource workloads, you have the latest information about the state of your Argo CD instances by enabling alerts for them. When the component workload pods such as application-controller, repo-server, or server of the corresponding Argo CD instance are unable to come up for certain reasons and there is a drift between the number of ready replicas and the number of desired replicas for a certain period of time, the Operator then triggers the alerts. You can enable and disable the setting for monitoring Argo CD custom resource workloads. Prerequisites You have access to the cluster as a user with the cluster-admin role. Red Hat OpenShift GitOps is installed in your cluster. The monitoring stack is configured in your cluster in the openshift-monitoring project. In addition, the Argo CD instance is in a namespace that you can monitor through Prometheus. The kube-state-metrics service is running in your cluster. Optional: If you are enabling monitoring for an Argo CD instance already present in a user-defined project, ensure that the monitoring is enabled for user-defined projects in your cluster. Note If you want to enable monitoring for an Argo CD instance in a namespace that is not watched by the default openshift-monitoring stack, for example, any namespace that does not start with openshift-* , then you must enable user workload monitoring in your cluster. This action enables the monitoring stack to pick up the created PrometheusRule. 5.16.1. Enabling Monitoring for Argo CD custom resource workloads By default, the monitoring configuration for Argo CD custom resource workloads is set to false . With Red Hat OpenShift GitOps, you can enable workload monitoring for specific Argo CD instances. As a result, the Operator creates a PrometheusRule object that contains alert rules for all the workloads managed by the specific Argo CD instances. These alert rules trigger the firing of an alert when the replica count of the corresponding component has drifted from the desired state for a certain amount of time. The Operator will not overwrite the changes made to the PrometheusRule object by the users. Procedure Set the .spec.monitoring.enabled field value to true on a given Argo CD instance: Example Argo CD custom resource apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: ... monitoring: enabled: true ... Verify whether an alert rule is included in the PrometheusRule created by the Operator: Example alert rule apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: argocd-component-status-alert namespace: openshift-gitops spec: groups: - name: ArgoCDComponentStatus rules: ... - alert: ApplicationSetControllerNotReady 1 annotations: message: >- applicationSet controller deployment for Argo CD instance in namespace "default" is not running expr: >- kube_statefulset_status_replicas{statefulset="openshift-gitops-application-controller statefulset", namespace="openshift-gitops"} != kube_statefulset_status_replicas_ready{statefulset="openshift-gitops-application-controller statefulset", namespace="openshift-gitops"} for: 1m labels: severity: critical 1 Alert rule in the PrometheusRule that checks whether the workloads created by the Argo CD instances are running as expected. 5.16.2. Disabling Monitoring for Argo CD custom resource workloads You can disable workload monitoring for specific Argo CD instances. Disabling workload monitoring deletes the created PrometheusRule. Procedure Set the .spec.monitoring.enabled field value to false on a given Argo CD instance: Example Argo CD custom resource apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: ... monitoring: enabled: false ... 5.16.3. Additional resources Enabling monitoring for user-defined projects 5.17. Viewing Argo CD logs You can view the Argo CD logs with the logging subsystem for Red Hat OpenShift. The logging subsystem visualizes the logs on a Kibana dashboard. The OpenShift Logging Operator enables logging with Argo CD by default. 5.17.1. Storing and retrieving Argo CD logs You can use the Kibana dashboard to store and retrieve Argo CD logs. Prerequisites The Red Hat OpenShift GitOps Operator is installed in your cluster. The logging subsystem for Red Hat OpenShift is installed with default configuration in your cluster. Procedure In the OpenShift Container Platform web console, go to the menu Observability Logging to view the Kibana dashboard. Create an index pattern. To display all the indices, define the index pattern as * , and click step . Select @timestamp for Time Filter field name . Click Create index pattern . In the navigation panel of the Kibana dashboard, click the Discover tab. Create a filter to retrieve logs for Argo CD. The following steps create a filter that retrieves logs for all the pods in the openshift-gitops namespace: Click Add a filter + . Select the kubernetes.namespace_name field. Select the is operator. Select the openshift-gitops value. Click Save . Optional: Add additional filters to narrow the search. For example, to retrieve logs for a particular pod, you can create another filter with kubernetes.pod_name as the field. View the filtered Argo CD logs in the Kibana dashboard. 5.17.2. Additional resources Installing the logging subsystem for Red Hat OpenShift using the web console 5.18. Running GitOps control plane workloads on infrastructure nodes You can use infrastructure nodes to prevent additional billing cost against subscription counts. You can use the OpenShift Container Platform to run certain workloads on infrastructure nodes installed by the Red Hat OpenShift GitOps Operator. This comprises the workloads that are installed by the Red Hat OpenShift GitOps Operator by default in the openshift-gitops namespace, including the default Argo CD instance in that namespace. Note Any other Argo CD instances installed to user namespaces are not eligible to run on infrastructure nodes. 5.18.1. Moving GitOps workloads to infrastructure nodes You can move the default workloads installed by the Red Hat OpenShift GitOps to the infrastructure nodes. The workloads that can be moved are: kam deployment cluster deployment (backend service) openshift-gitops-applicationset-controller deployment openshift-gitops-dex-server deployment openshift-gitops-redis deployment openshift-gitops-redis-ha-haproxy deployment openshift-gitops-repo-sever deployment openshift-gitops-server deployment openshift-gitops-application-controller statefulset openshift-gitops-redis-server statefulset Procedure Label existing nodes as infrastructure by running the following command: USD oc label node <node-name> node-role.kubernetes.io/infra= Edit the GitOpsService custom resource (CR) to add the infrastructure node selector: USD oc edit gitopsservice -n openshift-gitops In the GitOpsService CR file, add runOnInfra field to the spec section and set it to true . This field moves the workloads in openshift-gitops namespace to the infrastructure nodes: apiVersion: pipelines.openshift.io/v1alpha1 kind: GitopsService metadata: name: cluster spec: runOnInfra: true Optional: Apply taints and isolate the workloads on infrastructure nodes and prevent other workloads from scheduling on these nodes. USD oc adm taint nodes -l node-role.kubernetes.io/infra infra=reserved:NoSchedule infra=reserved:NoExecute Optional: If you apply taints to the nodes, you can add tolerations in the GitOpsService CR: spec: runOnInfra: true tolerations: - effect: NoSchedule key: infra value: reserved - effect: NoExecute key: infra value: reserved To verify that the workloads are scheduled on infrastructure nodes in the Red Hat OpenShift GitOps namespace, click any of the pod names and ensure that the Node selector and Tolerations have been added. Note Any manually added Node selectors and Tolerations in the default Argo CD CR will be overwritten by the toggle and the tolerations in the GitOpsService CR. 5.18.2. Additional resources To learn more about taints and tolerations, see Controlling pod placement using node taints . For more information on infrastructure machine sets, see Creating infrastructure machine sets . 5.19. Sizing requirements for GitOps Operator The sizing requirements page displays the sizing requirements for installing Red Hat OpenShift GitOps on OpenShift Container Platform. It also provides the sizing details for the default ArgoCD instance that is instantiated by the GitOps Operator. 5.19.1. Sizing requirements for GitOps Red Hat OpenShift GitOps is a declarative way to implement continuous deployment for cloud-native applications. Through GitOps, you can define and configure the CPU and memory requirements of your application. Every time you install the Red Hat OpenShift GitOps Operator, the resources on the namespace are installed within the defined limits. If the default installation does not set any limits or requests, the Operator fails within the namespace with quotas. Without enough resources, the cluster cannot schedule ArgoCD related pods. The following table details the resource requests and limits for the default workloads: Workload CPU requests CPU limits Memory requests Memory limits argocd-application-controller 1 2 1024M 2048M applicationset-controller 1 2 512M 1024M argocd-server 0.125 0.5 128M 256M argocd-repo-server 0.5 1 256M 1024M argocd-redis 0.25 0.5 128M 256M argocd-dex 0.25 0.5 128M 256M HAProxy 0.25 0.5 128M 256M Optionally, you can also use the ArgoCD custom resource with the oc command to see the specifics and modify them: oc edit argocd <name of argo cd> -n namespace 5.20. Troubleshooting issues in Red Hat OpenShift GitOps When working with Red Hat OpenShift GitOps, you might face issues related to performance, monitoring, configuration, and other aspects. This section helps you to understand those issues and provide solutions to resolve them. 5.20.1. Issue: Auto-reboot during Argo CD sync with machine configurations In the Red Hat OpenShift Container Platform, nodes are updated automatically through the Red Hat OpenShift Machine Config Operator (MCO). A Machine Config Operator (MCO) is a custom resource that is used by the cluster to manage the complete life cycle of its nodes. When an MCO resource is created or updated in a cluster, the MCO picks up the update, performs the necessary changes to the selected nodes, and restarts the nodes gracefully by cordoning, draining, and rebooting those nodes. It handles everything from the kernel to the kubelet. However, interactions between the MCO and the GitOps workflow can introduce major performance issues and other undesired behaviors. This section shows how to make the MCO and the Argo CD GitOps orchestration tool work well together. 5.20.1.1. Solution: Enhance performance in machine configurations and Argo CD When you are using a Machine Config Operator as part of a GitOps workflow, the following sequence can produce suboptimal performance: Argo CD starts an automated sync job after a commit to the Git repository that contains application resources. If Argo CD notices a new or an updated machine configuration while the sync operation is in process, MCO picks up the change to the machine configuration and starts rebooting the nodes to apply the change. If a rebooting node in the cluster contains the Argo CD application controller, the application controller terminates, and the application sync is aborted. As the MCO reboots the nodes in sequential order, and the Argo CD workloads can be rescheduled on each reboot, it can take some time for the sync to be completed. This results in an undefined behavior until the MCO has rebooted all nodes affected by the machine configurations within the sync. 5.20.2. Additional resources Preventing nodes from auto-rebooting during Argo CD sync with machine configs

Commands:
oc describe deployment gitops-operator-controller-manager -n openshift-operators
oc describe deployment gitops-operator-controller-manager -n openshift-operators
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: repo: extraRepoCommandArgs: - --max.combined.directory.manifests.size - 10M
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: applicationSet: env: - name: ARGOCD_GIT_MODULES_ENABLED value: "true"
oc describe deployment gitops-operator-controller-manager -n openshift-operators
oc describe deployment gitops-operator-controller-manager -n openshift-operators
oc describe deployment gitops-operator-controller-manager -n openshift-operators
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: sso: keycloak: rootCA: '<PEM encoded root certificate>' provider: keycloak .... ....
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: | ---- BEGIN CERTIFICATE ---- This is a dummy certificate Please place this section with appropriate rootCA ---- END CERTIFICATE ---- server: route: enabled: true
spec: extraConfig: oidc.tls.insecure.skip.verify: "true"
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: | ---- BEGIN CERTIFICATE ---- This is a dummy certificate Please place this section with appropriate rootCA ---- END CERTIFICATE ---- server: route: enabled: true
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: extraConfig: "admin.enabled": "true"
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: | ---- BEGIN CERTIFICATE ---- This is a dummy certificate Please place this section with appropriate rootCA ---- END CERTIFICATE ---- server: route: enabled: true
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: extraConfig: "admin.enabled": "true"
reason: ErrImagePull message: >- rpc error: code = Unknown desc = reading manifest sha256:ff4ad30752cf0d321cd6c2c6fd4490b716607ea2960558347440f2f370a586a8 in registry.redhat.io/openshift-gitops-1/argocd-rhel8: StatusCode: 404, <HTML><HEAD><TITLE>Error</TITLE></HEAD><BODY>
Argo service account does not have <random_verb> on <random_resource_type> in namespace <the_namespace_you_deleted>.
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak server: route: enabled: true
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: server: route: enabled: true labels: key1: value1 key2: value2
oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]'
oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}]
kind: ConfigMap apiVersion: v1 metadata: selfLink: /api/v1/namespaces/openshift-gitops/configmaps/argocd-cm resourceVersion: '112532' name: argocd-cm uid: f5226fbc-883d-47db-8b53-b5e363f007af creationTimestamp: '2021-04-16T19:24:08Z' managedFields: namespace: openshift-gitops labels: app.kubernetes.io/managed-by: argocd-cluster app.kubernetes.io/name: argocd-cm app.kubernetes.io/part-of: argocd data: "" 1 admin.enabled: 'true' statusbadge.enabled: 'false' resource.exclusions: | - apiGroups: - tekton.dev clusters: - '*' kinds: - TaskRun - PipelineRun ga.trackingid: '' repositories: | - type: git url: https://github.com/user-name/argocd-example-apps ga.anonymizeusers: 'false' help.chatUrl: '' url: >- https://argocd-cluster-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com "" 2 help.chatText: '' kustomize.buildOptions: '' resource.inclusions: '' repository.credentials: '' users.anonymous.enabled: 'false' configManagementPlugins: '' application.instanceLabelKey: ''
url: >- https://openshift-gitops-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator namespace: openshift-operators spec: channel: latest 1 installPlanApproval: Automatic name: openshift-gitops-operator 2 source: redhat-operators 3 sourceNamespace: openshift-marketplace 4
oc apply -f openshift-gitops-sub.yaml
oc get pods -n openshift-gitops
NAME READY STATUS RESTARTS AGE cluster-b5798d6f9-zr576 1/1 Running 0 65m kam-69866d7c48-8nsjv 1/1 Running 0 65m openshift-gitops-application-controller-0 1/1 Running 0 53m openshift-gitops-applicationset-controller-6447b8dfdd-5ckgh 1/1 Running 0 65m openshift-gitops-redis-74bd8d7d96-49bjf 1/1 Running 0 65m openshift-gitops-repo-server-c999f75d5-l4rsg 1/1 Running 0 65m openshift-gitops-server-5785f7668b-wj57t 1/1 Running 0 53m
oc delete gitopsservice cluster -n openshift-gitops
oc delete gitopsservice cluster -n <namespace>
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: repo: replicas: <number_of_replicas> server: replicas: <number_of_replicas> route: enabled: true path: / tls: insecureEdgeTerminationPolicy: Redirect termination: passthrough wildcardPolicy: None
oc label namespace <namespace> argocd.argoproj.io/managed-by=<instance_name> 1
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator spec: config: env: - name: DISABLE_DEFAULT_ARGOCD_CONSOLELINK value: 'true'
sum(argocd_app_info{dest_namespace=~"<your_defined_namespace>",health_status!=""}) by (health_status) 1
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator namespace: openshift-operators spec: config: env: - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES value: openshift-gitops, <list of namespaces of cluster-scoped Argo CD instances>
auth can-i create oauth -n openshift-gitops --as system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller
- verbs: - get - list - watch apiGroups: - '*' resources: - '*' - verbs: - get - list nonResourceURLs: - '*'
oc edit clusterrole argocd-server oc edit clusterrole argocd-application-controller
oc label node <node-name> node-role.kubernetes.io/infra=""
oc adm taint nodes -l node-role.kubernetes.io/infra infra=reserved:NoSchedule infra=reserved:NoExecute
apiVersion: pipelines.openshift.io/v1alpha1 kind: GitopsService metadata: name: cluster spec: runOnInfra: true
spec: runOnInfra: true tolerations: - effect: NoSchedule key: infra value: reserved - effect: NoExecute key: infra value: reserved
git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git
oc create -f openshift-gitops-getting-started/argo/app.yaml
oc get application -n openshift-gitops
oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secrets-cluster-role rules: - apiGroups: [""] resources: ["secrets"] verbs: ["*"]
kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: cluster-role-binding subjects: - kind: ServiceAccount name: openshift-gitops-argocd-application-controller namespace: openshift-gitops roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: grafana spec: channel: v4 installPlanApproval: Automatic name: grafana-operator source: redhat-operators sourceNamespace: openshift-marketplace
apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: ansible-automation-platform apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ansible-automation-platform-operator namespace: ansible-automation-platform spec: targetNamespaces: - ansible-automation-platform apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ansible-automation-platform namespace: ansible-automation-platform spec: channel: patch-me installPlanApproval: Automatic name: ansible-automation-platform-operator source: redhat-operators sourceNamespace: openshift-marketplace
git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git
oc create -f openshift-gitops-getting-started/argo/app.yaml
oc create -f openshift-gitops-getting-started/argo/app.yaml
oc get application -n openshift-gitops
oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
oc edit deployment spring-petclinic -n spring-petclinic
oc scale deployment spring-petclinic --replicas 2 -n spring-petclinic
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: notifications: enabled: true
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: argocd 1 namespace: openshift-gitops 2 spec: redis: autotls: openshift 3 ha: enabled: true 4
oc patch argocds.argoproj.io <instance-name> --type=merge -p '{"spec":{"redis":{"autotls":"openshift"}}}'
oc get pods -n <namespace> 1
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m
oc get secrets argocd-operator-redis-tls -n <namespace> 1
NAME TYPE DATA AGE argocd-operator-redis-tls kubernetes.io/tls 2 30s
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: argocd 1 namespace: openshift-gitops 2 spec: ha: enabled: true 3
oc get pods -n <namespace> 1
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m
openssl req -new -x509 -sha256 -subj "/C=XX/ST=XX/O=Testing/CN=redis" -reqexts SAN -extensions SAN -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1 -keyout /tmp/redis.key -out /tmp/redis.crt -newkey rsa:4096 -nodes -sha256 -days 10
Generating a RSA private key ...............++++ ............................++++ writing new private key to '/tmp/redis.key'
openssl req -new -x509 -sha256 -subj "/C=XX/ST=XX/O=Testing/CN=redis" -reqexts SAN -extensions SAN -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis-ha-haproxy.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1 -keyout /tmp/redis-ha.key -out /tmp/redis-ha.crt -newkey rsa:4096 -nodes -sha256 -days 10
Generating a RSA private key ...............++++ ............................++++ writing new private key to '/tmp/redis-ha.key'
cd /tmp
ls
redis.crt redis.key
redis-ha.crt redis-ha.key
oc create secret tls argocd-operator-redis-tls --key=/tmp/redis.key --cert=/tmp/redis.crt
oc create secret tls argocd-operator-redis-tls --key=/tmp/redis-ha.key --cert=/tmp/redis-ha.crt
secret/argocd-operator-redis-tls created
oc annotate secret argocd-operator-redis-tls argocds.argoproj.io/name=<instance-name> 1
secret/argocd-operator-redis-tls annotated
oc get pods -n <namespace> 1
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m
spec: labels: openshift.gitops/environment: <environment_name> destination: namespace: <environment_name>
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: dev-env 1 namespace: openshift-gitops spec: labels: openshift.gitops/environment: dev-env destination: namespace: dev-env
apiVersion: v1 kind: Namespace metadata: annotations: app.openshift.io/vcs-uri: <application_source_url> app.openshift.io/vcs-ref: <branch_reference> name: <environment_name> 1
apiVersion: v1 kind: Namespace metadata: annotations: app.openshift.io/vcs-uri: https://example.com/<your_domain>/<your_gitops.git> app.openshift.io/vcs-ref: main labels: argocd.argoproj.io/managed-by: openshift-gitops name: dev-env
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: openshift-oauth spec: dex: openShiftOAuth: true 1 groups: 2 - default rbac: 3 defaultPolicy: 'role:readonly' policy: | g, cluster-admins, role:admin scopes: '[groups]'
oc adm groups new cluster-admins
oc adm groups add-users cluster-admins USER
oc adm policy add-cluster-role-to-group cluster-admin cluster-admins
spec: config: env: - name: DISABLE_DEX value: "true"
spec: sso: provider: dex dex: openShiftOAuth: true
dex: openShiftOAuth: true resources: limits: cpu: memory: requests: cpu: memory:
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: "<PEM-encoded-root-certificate>" 1 server: route: enabled: true
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: extraConfig: oidc.tls.insecure.skip.verify: "true" sso: provider: keycloak keycloak: rootCA: ""
oc -n argocd get route keycloak NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD keycloak keycloak-default.apps.ci-ln-******.origin-ci-int-aws.dev.**.com keycloak <all> reencrypt None
oc -n argocd get pods NAME READY STATUS RESTARTS AGE keycloak-1-2sjcl 1/1 Running 0 45m
oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_USERNAME SSO_ADMIN_USERNAME=<username>
oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD SSO_ADMIN_PASSWORD=<password>
policy.csv: <name>, <email>, role:admin
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: server: route: enabled: true
oc edit argocd [argocd-instance-name] -n [namespace]
metadata rbac: policy: 'g, rbacsystem:cluster-admins, role:admin' scopes: '[groups]'
metadata rbac: policy: <name>, <email>, role:<admin> scopes: '[groups]'
oc -n openshift-gitops patch argocd openshift-gitops --type='json' -p='[{"op": "add", "path": "/spec/sso", "value": {"provider": "keycloak", "resources": {"requests": {"cpu": "512m", "memory": "512Mi"}, "limits": {"cpu": "1024m", "memory": "1024Mi"}} }}]'
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example spec: server: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 125m memory: 128Mi route: enabled: true applicationSet: resources: limits: cpu: '2' memory: 1Gi requests: cpu: 250m memory: 512Mi repo: resources: limits: cpu: '1' memory: 512Mi requests: cpu: 250m memory: 256Mi dex: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 250m memory: 128Mi redis: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 250m memory: 128Mi controller: resources: limits: cpu: '2' memory: 2Gi requests: cpu: 250m memory: 1Gi
-n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/cpu", "value":"1"}]' -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/memory", "value":"512Mi"}]'
-n argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/cpu"}]' -n argocd argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/memory"}]'
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: monitoring: enabled: true
apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: argocd-component-status-alert namespace: openshift-gitops spec: groups: - name: ArgoCDComponentStatus rules: - alert: ApplicationSetControllerNotReady 1 annotations: message: >- applicationSet controller deployment for Argo CD instance in namespace "default" is not running expr: >- kube_statefulset_status_replicas{statefulset="openshift-gitops-application-controller statefulset", namespace="openshift-gitops"} != kube_statefulset_status_replicas_ready{statefulset="openshift-gitops-application-controller statefulset", namespace="openshift-gitops"} for: 1m labels: severity: critical
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: monitoring: enabled: false
oc label node <node-name> node-role.kubernetes.io/infra=
oc edit gitopsservice -n openshift-gitops
apiVersion: pipelines.openshift.io/v1alpha1 kind: GitopsService metadata: name: cluster spec: runOnInfra: true
oc adm taint nodes -l node-role.kubernetes.io/infra infra=reserved:NoSchedule infra=reserved:NoExecute
spec: runOnInfra: true tolerations: - effect: NoSchedule key: infra value: reserved - effect: NoExecute key: infra value: reserved
edit argocd <name of argo cd> -n namespace