Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 1. Red Hat OpenShift GitOps release notes

Note

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.

1.1. Compatibility and support matrix

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

In the table, features are marked with the following statuses:

TP: Technology Preview
GA: General Availability
NA: Not Applicable

Important

In OpenShift Container Platform 4.13, the stable channel has been removed. Before upgrading to OpenShift Container Platform 4.13, if you are already on the stable channel, choose the appropriate channel and switch to it.

OpenShift GitOps	Component Versions								OpenShift Versions
Version	`kam`	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).
Important
In Red Hat OpenShift GitOps 1.13 or later, the Red Hat OpenShift GitOps Application Manager CLI, kam, was deprecated and is planned to be removed in a future release. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements and will be removed. As an alternative to the Red Hat OpenShift GitOps Application Manager CLI, kam, you can use the Argo CD CLI that is available from Red Hat OpenShift GitOps Operator v1.12.
RH SSO is an abbreviation for Red Hat SSO.

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 1.1. Technology Preview tracker
Feature	TP in Red Hat OpenShift GitOps versions	GA in Red Hat OpenShift GitOps versions
The GitOps `argocd` CLI tool	1.12.0	NA
Argo CD application sets in non-control plane namespaces	1.12.0	NA
The `round-robin` cluster sharding algorithm	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

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.

1.3. Release notes for Red Hat OpenShift GitOps 1.14.1

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.

1.3.1. Errata updates

1.3.1.1. RHBA-2024:8625 - Red Hat OpenShift GitOps 1.14.1 security update advisory

Issued: 2024-10-29

The list of security fixes that are included in this release is documented in the following advisory:

RHBA-2024:8625

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

1.3.2. Fixed issues

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

1.3.3. Breaking change

1.3.3.1. Additional configurations for cluster-scoped rollouts instance installation

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
Note
The cluster-scoped rollouts installation functionality change does not impact the installation behavior of the namespace-scoped rollouts installation.
Example: Configuring the CLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES environment variable
```
apiVersion: 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.

1.4. Release notes for Red Hat OpenShift GitOps 1.14.0

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.

1.4.1. Errata updates

1.4.1.1. RHEA-2024:6787 - Red Hat OpenShift GitOps 1.14.0 security update advisory

Issued: 2024-09-18

The list of security fixes that are included in this release are documented in the following advisory:

RHEA-2024:6787

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

1.4.2. New features

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
Example
```
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
Note
The signature verification does not function with the templated project field in ApplicationSet CRD Git Generator.

1.4.3. Fixed issues

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
Note
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.
Example
```
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.

1.4.4. Breaking change

1.4.4.1. Cluster secrets with empty secret values

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