$ oc describe deployment gitops-operator-controller-manager -n openshift-gitops-operator
For additional information about the OpenShift GitOps lifecycle and supported platforms, refer to the OpenShift Operator Life Cycles and Red Hat OpenShift Container Platform Life Cycle Policy. |
Release notes contain information about new and deprecated features, breaking changes, and known issues. The following release notes apply for the most recent OpenShift GitOps releases on OpenShift Container Platform.
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 About Red Hat OpenShift GitOps.
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
In OpenShift Container Platform 4.13, the |
OpenShift GitOps | Component Versions | OpenShift Versions | |||||||
---|---|---|---|---|---|---|---|---|---|
Version |
|
Argo CD CLI |
Helm |
Kustomize |
Argo CD |
Argo Rollouts |
Dex |
RH SSO |
|
1.14.0 |
0.0.51 TP |
2.12.3 TP |
3.15.2 GA |
5.4.2 GA |
2.12.3 GA |
1.7.1 GA |
2.39.1 GA |
7.6.0 GA |
4.12-4.17 |
1.13.0 |
0.0.51 TP |
2.11.3 TP |
3.14.4 GA |
5.2.1 GA |
2.11.3 GA |
1.6.6 GA |
2.37.0 GA |
7.6.0 GA |
4.12-4.16 |
1.12.0 |
0.0.51 TP |
2.10.3 TP |
3.14.0 GA |
5.2.1 GA |
2.10.3 GA |
1.6.0 TP |
2.36.0 GA |
7.6.0 GA |
4.12-4.15 |
kam
is the Red Hat OpenShift GitOps Application Manager command-line interface (CLI).
In Red Hat OpenShift GitOps 1.13 or later, the Red Hat OpenShift GitOps Application Manager CLI, |
RH SSO is an abbreviation for Red Hat SSO.
The features mentioned in the following table are currently in Technology Preview (TP). These experimental features are not intended for production use.
Feature | TP in Red Hat OpenShift GitOps versions | GA in Red Hat OpenShift GitOps versions |
---|---|---|
The GitOps |
1.12.0 |
NA |
Argo CD application sets in non-control plane namespaces |
1.12.0 |
NA |
The |
1.10.0 |
NA |
Dynamic scaling of shards |
1.10.0 |
NA |
Argo Rollouts |
1.9.0 |
1.13.0 |
ApplicationSet Progressive Rollout Strategy |
1.8.0 |
NA |
Multiple sources for an application |
1.8.0 |
NA |
Argo CD applications in non-control plane namespaces |
1.7.0 |
1.13.0 |
The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console |
1.1.0 |
NA |
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.
Red Hat OpenShift GitOps 1.14.2 is now available on OpenShift Container Platform 4.12, 4.13, 4.14, 4.15, 4.16, and 4.17.
Issued: 2024-11-20
The list of security fixes that are included in this release is documented in the following advisory:
If you have installed the Red Hat OpenShift GitOps Operator in the default namespace, run the following command to view the container images in this release:
$ oc describe deployment gitops-operator-controller-manager -n openshift-gitops-operator
Before this update, the New App panel behaved unexpectedly as it reopened immediately after being closed, and typing in fields caused the cursor and text to flash repeatedly. With this fix, the New App panel operates as intended. GITOPS-5671
Before this update, when using the dynamic scaling feature, application controller pods consumed high memory and clusters were not distributed properly across shards. This update ensures that clusters are distributed across shards. GITOPS-3465
For more information, see Enabling dynamic scaling of shards in the web console.
Red Hat OpenShift GitOps 1.14.1 is now available on OpenShift Container Platform 4.13, 4.14, 4.15, 4.16, and 4.17.
Issued: 2024-10-29
The list of security fixes that are included in this release is documented in the following advisory:
If you have installed the Red Hat OpenShift GitOps Operator in the default namespace, run the following command to view the container images in this release:
$ oc describe deployment gitops-operator-controller-manager -n openshift-gitops-operator
Before this update, resource limits were set on the operator container as a recommended practice. However, these limits caused functional issues on clusters with a large number of secrets and config maps because the operator manager, a controller that manages the lifecycle of Argo CD components, required more memory than allowed by these limits. With this update, the resource limits set on the manager container have been removed to minimize the impact on functionality. Efforts are focused to optimize memory consumption for future releases. GITOPS-5665
Before this update, Argo CD could not obtain the appropriate transport layer security (TLS) certificate for Helm Open Container Initiative (OCI) registries when the URL included a path or port number. With this update, a fix is introduced in upstream Argo CD to correctly parse the URL and return a valid certificate. GITOPS-5081
Before this update, you could not log in to the Argo CD web console UI on a Red Hat OpenShift Service on Amazon Web Services (AWS) cluster that includes a GitOps Operator and an Argo CD instance configured with Dex-based SSO, after the cluster resumed from hibernation. The login screen would display an error indicating an invalid redirect Uniform Resource Identifier (URI) in the Dex configuration. This update fixes the issue by ensuring that the correct Dex redirect URL is updated in the Argo CD configuration whenever the Argo CD server route is modified. GITOPS-4358
When you upgrade to Red Hat OpenShift GitOps v1.14, if you want to create the cluster-scoped rollouts installation outside the default installation namespace, openshift-gitops
, you must host it in the CLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES
environment variable of the Subscription
resource. The Red Hat OpenShift GitOps Operator does not support cluster-scoped rollouts installation if the namespace is not defined in the CLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES
environment variable.
In previous versions of Red Hat OpenShift GitOps, Argo Rollouts used the NAMESPACE_SCOPED_ARGO_ROLLOUTS_NAMESPACES
environment variable of the Subscription
resource to check if you can create a cluster-scoped rollouts instance in the user-defined namespace. GITOPS-5640
The cluster-scoped rollouts installation functionality change does not impact the installation behavior of the namespace-scoped rollouts installation. |
CLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES
environment variableapiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: argo-operator
spec:
config:
env:
- name: NAMESPACE_SCOPED_ARGO_ROLLOUTS
value: 'false' (1)
- name: CLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES
value: <list_of_namespaces_in_the_cluster-scoped_Argo_CD_instances> (2)
...
1 | Specify this value to enable or disable the cluster-scoped installation. If the value is set to 'false' , it means that the you have enabled cluster-scoped installation. If it is set to 'true' , it means that you have enabled namespace-scoped installation. If the value is empty, it is set to false . |
2 | Specifies a comma-separated list of namespaces that can host a cluster-scoped Argo CD instance, for example test-123-cluster-scoped,test-456-cluster-scoped . |
Red Hat OpenShift GitOps 1.14.0 is now available on OpenShift Container Platform 4.12, 4.13, 4.14, 4.15, 4.16, and 4.17.
Issued: 2024-09-18
The list of security fixes that are included in this release are documented in the following advisory:
If you have installed the Red Hat OpenShift GitOps Operator in the default namespace, run the following command to view the container images in this release:
$ oc describe deployment gitops-operator-controller-manager -n openshift-gitops-operator
With this update, users can customize permissions for the Application Controller component in a cluster-scoped Argo CD instance. The Red Hat OpenShift GitOps Operator creates an aggregated cluster role, and you can configure its permissions to combine several cluster roles into a single one. GITOPS-4681
With this update, the following enhancements have been introduced for multi-source application:
You can access revision history and roll back to a specific version of a multi-source application. The Details view panel displays the most recent revision or commit details for each source in the multi-source application. The History and Rollback panels display the revision history associated with each source; you can select the version you want to roll back to. GITOPS-4647
The new SOURCES tab displays all source parameters of a multi-source application. With the SOURCES tab, you can view and edit the parameter values by using a form in the web UI. GITOPS-4192
With this update, you can extend the repo server storage by mounting persistent volumes. The repo server utilizes the EmptyDir
default storage volume, which has limitations and might prove inadequate in scenarios involving numerous repositories, sizable repositories, or repositories containing large manifests. You can mount additional storage on demand by using the .spec.repo.volumes
and .spec.repo.volumeMounts
fields in the Argo CD custom resource (CR). GITOPS-4646
For more information, refer to the HA for Repo Server.
With this update, you can implement an alternative sharding algorithm that utilizes consistent hashing with bounded loads. The algorithm ensures a uniform distribution of managed clusters across shards while minimizing the need for reshuffling during configuration changes, such as adjustments in the number of managed clusters or shards. GITOPS-3584
With this update, Red Hat OpenShift GitOps provides support for the sidecar
and init
containers for the Server and Application Controller components. You can configure the sidecar
and init
containers by using the spec.server.sidecarContainers
, spec.controller.sidecarContainers
, spec.server.initContainers
, and spec.controller.initContainers
fields in the Argo CD CR. GITOPS-5010
apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
name: example-argocd
spec:
server:
initContainers:
- name: argocd-init
image: nginx:latest
sidecarContainers:
- name: cmp
image: busybox
With this update, you can expose Argo CD Application labels on Kubernetes events generated by Argo CD. When events are created for applications that have specific label keys defined in the resource.includeEventLabelKeys
field within the argocd-cm
config map, the controller adds the matching labels to these events. This enhancement facilitates the filtering and processing of events based on the application labels. To set the resource.includeEventLabelKeys
field in a GitOps environment, use the .spec.extraConfig
field in the Argo CD CR. The GitOps Operator automatically adds these fields from the .spec.extraConfig
field into the argocd-cm
config map. GITOPS-3233
apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
name: argocd-sample (1)
namespace: default (2)
spec:
extraConfig:
resource.includeEventLabelKeys: team,env* (3)
1 | Specifies the name of the Argo CD instance. |
2 | Specifies the namespace where the Argo CD is installed. |
3 | Specifies the label keys that match and are added onto Application events. |
For more information, see Labels on Application Events.
With this update, you can verify commit signatures for ApplicationSet
CRD created using Git generators. GITOPS-3049
The signature verification does not function with the templated project field in |
Before this update, users could not execute a rollback for multi-source applications in the Argo CD web UI or CLI. This update fixes the issues, and users can now carry out rollbacks for multi-source applications using the Argo CD web UI or CLI. GITOPS-3996
Before this update, the ApplicationSet
Controller role did not include the list
and watch
permissions for the AppProject
resource. As a result, there were errors during the application generation process. This update fixes the issue by granting necessary permissions to the ApplicationSet
Controller role. GITOPS-5401
Before this update, Argo CD was unable to synchronize PersistentVolume
resources on OpenShift Container Platform v4.16 due to the introduction of the new .status.lastPhaseTransitionTime
field in Kubernetes v1.29. This update fixes the issue by modifying the Kubernetes static scheme in Argo CD. GITOPS-5167
Before this update, the Red Hat OpenShift GitOps Operator included a race condition where the OpenShift Service CA created the TLS secret before the default TLS termination policy was set. As a result, the default policy was set as Passthrough
instead of Reencrypt
. This update fixes this race condition by verifying whether the secret was created by the OpenShift Service CA, ensuring that Reencrypt
is used as the correct default policy. GITOPS-4947
Before this update, you could not log in to the Argo CD web console UI after a Red Hat OpenShift Service on AWS cluster, that includes a GitOps Operator and an Argo CD instance configured with Dex-based SSO, resumed from hibernation. The login screen would display an error indicating an invalid redirect URI in the Dex configuration. This update fixes the issue by ensuring that the correct Dex redirect URL is updated in the Argo CD configuration whenever the Argo CD server route is modified. GITOPS-4358
Before this update, adding a self-signed TLS certificate for the ApplicationSet GitLab SCM Provider did not function as intended, as the certificate failed to mount on the required volume. This update fixes the issue by correcting the volume mount path and providing documentation on the usage of this feature. Users are now required to ensure that the config map’s name is argocd-appset-gitlab-scm-tls-certs-cm
. GITOPS-4801
The key for the TLS Certificate config map must be labeled 'cert' because this serves as the file name for the mounted certificate. Other key names will not be effective due to an upstream bug that will be resolved in a future release. The following is an example of a config map you can use to mount your TLS certificate. |
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-appset-gitlab-scm-tls-certs-cm (1)
namespace: test-1-32-appsets-scm-tls-mount (2)
data:
cert: |
-----BEGIN CERTIFICATE-----
... (certificate contents) ...
-----END CERTIFICATE-----
1 | Specifies the name of the ApplicationSet GitLab SCM Provider. |
2 | Specifies the namespace where the ApplicationSet GitLab SCM Provider is defined. |
For more information, see Add Self-signed TLS Certificate for Gitlab SCM Provider to ApplicationSet Controller.
When you upgrade to Red Hat OpenShift GitOps v1.14, cluster secrets with an empty project value are no longer classified as global secrets applicable to all Applications
and ApplicationSets
resources.
In previous versions of GitOps, any Application
or ApplicationSet
resource could use a cluster secret that matches the URL specified in the repoUrl
field. Starting from Red Hat OpenShift GitOps v1.14, only cluster secrets scoped to an application’s project will be considered for matching a repository URL.
As a result, if a cluster secret is designated to project A, an application assigned to project B will be unable to access that secret. To allow applications across various projects to use cluster secrets, you must remove the project
field.
For more information, see Cluster secret scoping changes. GITOPS-5623