Este conteúdo não está disponível no idioma selecionado.
Chapter 1. Red Hat OpenShift GitOps release notes
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
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 |
| 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).ImportantIn 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.
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 |
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:
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 theCLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES
environment variable of theSubscription
resource. The Red Hat OpenShift GitOps Operator does not support cluster-scoped rollouts installation if the namespace is not defined in theCLUSTER_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 theSubscription
resource to check if you can create a cluster-scoped rollouts instance in the user-defined namespace. GITOPS-5640NoteThe 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 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 tofalse
. - 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:
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-4646For 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
andinit
containers for the Server and Application Controller components. You can configure thesidecar
andinit
containers by using thespec.server.sidecarContainers
,spec.controller.sidecarContainers
,spec.server.initContainers
, andspec.controller.initContainers
fields in the Argo CD CR. GITOPS-5010apiVersion: 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 theargocd-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 theresource.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 theargocd-cm
config map. GITOPS-3233Example
apiVersion: argoproj.io/v1beta1 kind: ArgoCD metadata: name: argocd-sample 1 namespace: default 2 spec: extraConfig: resource.includeEventLabelKeys: team,env* 3
For more information, see Labels on Application Events.
With this update, you can verify commit signatures for
ApplicationSet
CRD created using Git generators. GITOPS-3049NoteThe 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 thelist
andwatch
permissions for theAppProject
resource. As a result, there were errors during the application generation process. This update fixes the issue by granting necessary permissions to theApplicationSet
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 ofReencrypt
. This update fixes this race condition by verifying whether the secret was created by the OpenShift Service CA, ensuring thatReencrypt
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-4801NoteThe 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-----
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
andApplicationSets
resources.In previous versions of GitOps, any
Application
orApplicationSet
resource could use a cluster secret that matches the URL specified in therepoUrl
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