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 OpenShift GitOps Component Versions OpenShift Versions Version kam Helm Kustomize Argo CD ApplicationSet Dex RH SSO 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 an abbreviation for Red Hat OpenShift GitOps Application Manager (kam). "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 OCP versions GA in OCP versions Argo CD applications in non-control plane namespaces 4.8, 4.9, 4.10, 4.11, 4.12 NA The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console 4.7, 4.8, 4.9, 4.10, 4.11, 4.12 NA Argo CD Notifications controller 4.8, 4.9, 4.10, 4.11, 4.12 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.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.3.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.4. 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.4.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.5. 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.5.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.6. 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.6.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.6.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.7. 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.7.1. Fixed issues The following issues have been resolved in the current release: Before this update, the application controllers in a large set of applications 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 could not be validated when it is set up with a certificate that was not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate that 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.8. 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.8.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 control the keycloak configurations are moved to .spec.sso.keycloak . The parameters of the .spec.dex field are 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 an optional workload that can be enabled or disabled by using the .spec.notifications.enabled parameter in the Argo CD custom resource definition. The Argo CD Notifications controller is 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 task runs are added by default. Argo CD prunes these resources by default. These resource exclusions are added to new Argo CD instances created in 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 Argo CD uses by setting the resourceTrackingMethod parameter in the Argo CD Operand's custom resource definition. 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 specified entries 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 configures Argo CD workloads with the correct permissions to satisfy Pod Security admission, which was enabled in 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 is secured using 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. Installations in restricted environments are not supported on IBM Z and IBM Power. 5.1.8.2. Fixed issues The following issues have been resolved in the current release: Before this update, the system:serviceaccount:argocd:gitops-argocd-application-controller controller did not create a "prometheusrules" resource in the monitoring.coreos.com API group in the namespace webapps-dev . This update fixes this issue, and Red Hat OpenShift GitOps can 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. 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 , an init daemon that creates processes and reaps zombies processes, to the ApplicationSet controller. This ensures that a SIGTERM signal is correctly passed to the running process, preventing it from being a zombie process. GITOPS-2108 5.1.8.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.9. 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.9.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.10. 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.10.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.11. 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.11.1. Fixed issues The following issues have been resolved in the current release: Before this update, the application controllers in a large set of applications 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 could not be validated when it was set up with a certificate that was not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate that 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.12. 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.12.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.12.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.12.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.13. 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.13.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.14. 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.14.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 was 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 v1.0.0 and later were vulnerable to a cross-site scripting bug. As a result, an unauthorized users was able to inject JavaScript links in the UI. 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 was able to leak sensitive YAML files from Argo CD's repo-server. This issue is now fixed. CVE-2022-31036 5.1.15. 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.15.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.16. 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.16.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 now fixed . 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 was able to leak sensitive files from Argo CD's repo-server. This issue is now fixed. CVE-2022-24904 5.1.17. 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.17.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 named latest is added. This channel 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 of 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 of the release versions are 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 Container Platform credentials including the kube:admin credential. The RH-SSO supports and configures Argo CD instances for Role-based Access Control (RBAC) using OpenShift Container Platform groups. The RH-SSO supports 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, 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 is indicated 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.17.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 was 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, when 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, when creating a namespace with the managed-by label, a lot of RoleBinding resources on the new namespace were created. This update fixes the issue and Red Hat OpenShift GitOps removes the irrelevant Role and RoleBinding resources created by the versions. GITOPS-1548 5.1.17.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 Container Platform clusters. GITOPS-1920 5.1.18. 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.18.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.19. 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.19.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 could not be validated when it was set up with a certificate that was not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate that 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.20. 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.20.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.20.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.20.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.21. 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.21.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.22. 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.22.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.23. 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.23.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.24. 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.24.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.25. 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.25.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.26. 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.26.1. New features The current release adds the following improvements. This enhancement upgrades Red Hat OpenShift GitOps Application Manager (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.26.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 (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 kam. 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.26.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.27. 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.27.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.28. 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.28.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.29. 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.29.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.29.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.30. 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.30.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.31. 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.31.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.31.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.31.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.32. 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.32.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.33. 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.33.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 (kam) TP 5.1.33.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.34. 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.34.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 (kam) TP 5.1.34.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.34.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.34.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.35. 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.35.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 (kam) TP 5.1.35.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.35.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.35.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.35.5. Breaking Change 5.1.35.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. 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. 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. Note To login with your OpenShift Container Platform credentials, select the LOG IN VIA OPENSHIFT option in the Argo CD user interface. 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. 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 product-title cluster as an administrator. You have installed the gitops-title Operator in your cluster. You have logged into Argo CD instance. 5.5.1. Using an Argo CD instance to manage cluster-scoped resources To manage cluster-scoped resources, update the existing Subscription object for the gitops-title 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.5.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.5.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. 5.5.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.5.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/cluster.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.5.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.5.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.5.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.5.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.5.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.5.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.6. 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.6.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.6.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/cluster.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.6.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.7. 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.7.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.7.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.7.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.7.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.8. Monitoring health information for application resources and deployments The environment details page displays the health status of the application resources, such as routes, synchronization status, deployment configuration and deployment history. 5.8.1. 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 . Argo CD applications are in sync. 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. If the application is out of sync or degraded applications the respecting icons are displayed under the Resources . Hover over the icons to see the health status and the sync status. The icons are: For degraded , the broken heart icon is displayed. For out of sync , the yellow yield icon is displayed. 5.9. 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). 5.9.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.9.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.9.2. Disabling Dex Dex is installed by default for all the Argo CD instances created by the Operator. You can disable Dex. 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.10. 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. Argo CD is installed on the cluster. 5.10.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 following section from the Argo CD Custom Resource (CR), and save the CR: dex: openShiftOAuth: true resources: limits: cpu: memory: requests: cpu: memory: Configure Keycloak by editing the Argo CD CR, and updating the value for the provider parameter as keycloak . For example: apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak server: route: enabled: true Note The Keycloak instance takes 2-3 minutes to install and run. 5.10.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=Cqid54Ih Get the Keycloak password: USD oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD SSO_ADMIN_PASSWORD=GVXxHifH 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.10.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.11. 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.11.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.11.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.12. 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.12.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.13. 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.13.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

Commands:
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: 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/cluster.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/cluster.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: 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"
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 server: route: enabled: true
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=Cqid54Ih
oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD SSO_ADMIN_PASSWORD=GVXxHifH
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"}} }}]'
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