×

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.

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

OpenShift GitOps Component Versions OpenShift Versions Support status

Version

kam

Helm

Kustomize

Argo CD

ApplicationSet

Dex

1.3.0

0.0.40

3.6.0

4.2.0

2.1.2

0.2.0

2.28.0

4.7-4.9

GA

1.2.0

0.0.38

3.5.0

3.9.4

2.0.5

0.1.0

N/A

4.8

GA

1.1.0

0.0.32

3.5.0

3.9.4

2.0.0

N/A

N/A

4.7

GA

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.

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, and 4.9.

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

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, and 4.9.

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 environment details view 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

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

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.

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.7 and 4.8.

Support matrix

Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.

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 1. 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

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

Release notes for Red Hat OpenShift GitOps 1.2

Red Hat OpenShift GitOps 1.2 is now available on OpenShift Container Platform 4.7, 4.8, and 4.9.

Support matrix

Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.

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 2. Support matrix
Feature Red Hat OpenShift GitOps 1.2

Argo CD

GA

Argo CD ApplicationSet

TP

Red Hat OpenShift GitOps Application Manager (kam)

TP

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.

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

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.

    $ 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.

    $ 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.

Release notes for Red Hat OpenShift GitOps 1.1

Red Hat OpenShift GitOps 1.1 is now available on OpenShift Container Platform 4.7.

Support matrix

Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.

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 3. Support matrix
Feature Red Hat OpenShift GitOps 1.1

Argo CD

GA

Argo CD ApplicationSet

TP

Red Hat OpenShift GitOps Application Manager (kam)

TP

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).

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

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

Breaking Change

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:

  1. 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.
  2. Delete the default argocd-cluster instance.

  3. Edit the new argocd-cm.yml config map file to restore the entire data section manually.

  4. 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
  5. Login to the Argo CD cluster and verify that the previous configurations are present.