Cloudera on Cloud: March 2025 Release Summary

The Release Summary of Cloudera Public Cloud summarizes major features introduced in Management Console, Data Hub, and data services.

Cloudera AI

Cloudera AI 2.0.47-b360 introduces the following changes:

Fixed Issues

Cloudera AI Workbench

Previously, when users try to create a session, the ssh: This private key is passphrase protected error was displayed. This issue is now resolved. (DSE-426980)

Cloudera AI 2.0.47-b365 introduces the following changes:

Fixed Issues

Cloudera AI Workbench

The issue of sessions and pods getting stuck in the Stopping state has been resolved. (DSE-42144)
Pods in an Error or Stuck state within Cloudera AI Workbenches are now being properly garbage-collected. (DSE-43549)
Reduced the frequency of initialization failures for user workloads that launch immediately after node autoscaling. (DSE-43311)

Cloudera AI Platform

Previously, users with MLAdmin roles were initially assigned the MLUser role during the first sync, but their permissions are updated correctly in subsequent syncs or when they log in. This issue is now resolved. (DSE-42775)

Cloudera Data Engineering

Cloudera Data Engineering 1.23.1-H1 introduces the following changes:

This release does not contain new features, but includes the following fixes:

DEX-15814: AirflowAPI list_runs_by_id fails with ‘NoneType’ object has no attribute ‘strftime’
Cloudera Data Engineering Airflow Run Status updates did not work, which could lead to duration mismatch of Job duration versus the actual Airflow Dag Run duration, or it could lead to run status mismatch, or both. This happened when the same Airflow Job was triggered (AdHoc) multiple times and there was a limit on how many parallel DAGs could run at the same time. When the limit was reached, the DAG Runs were queued. As long as there were queued Airflow DAG Runs with None start_date, the Cloudera Data Engineering Job Run status updates did not work. Depending on the workload, this could take a long time. When this issue was present, Cloudera Data Engineering Jobs could not be killed. The state changed to Killed, but it changed back to the previous state. When this issue was present, the airflow-api logs listed: Could not search DAG runs: 'NoneType' object has no attribute 'strftime'.

DEX-15813: Cloudera Data Engineering killed job state can go back to previous state
Jobs could not be killed. When you tried to kill a Cloudera Data Engineering Airflow Job that was in running state, the Cloudera Data Engineering Job state changed to killed for a couple of seconds, but then it changed back to the previous state.

DEX-16304: Eliminate “Failed to parse DAG run start date” error logs when startDate is empty
If the start_date was zero for an Airflow DAG Run, an unnecessary error log was created.

DEX-16232: Fix already existing DAG check in airflow-api
A Cloudera Data Engineering Airflow Job could become corrupted during Cloudera Data Engineering Job creation, making it unusable for further management. The existing Airflow DAG check during Airflow Job creation did not handle OS-related issues properly (for example: NFS mount issue). If it happened, the metadata of an existing DAG could become corrupted. Corrupted Cloudera Data Engineering Airflow Jobs could not be deleted.

DEX-14724: Deletion logic prevents Cloudera Data Engineering Jobs from being deleted
A corrupted Airflow Job could not be deleted through the CLI, the REST API, or the UI.

DEX-15842: Cache the service account for consecutive job launches
When a large number of Jobs were submitted, during the Job launch, the service account check failed due to the Kubernetes API limit and the default timeout. Job submission failed with the following error: could not create user service account: client rate limiter.

DEX-15957: runtime-api pod restart causes RunDagMonitor to fetch all the DAG runs (airflowapi DoS)
Cloudera Data Engineering Airflow Job CRUD operations and Job Run Status updates did not work on Virtual Clusters with big Airflow DAG Run history. The airflow-api crashed after the jobs-api restarted if there were at least 400 000 Airflow DAG Runs in the Virtual Cluster.

Cloudera Data Hub

The latest version of Cloudera Data Hub introduces the following changes:

Added Stale cluster status
Stale cluster status has been added to the list of cluster statuses to express a status where we have no information from the cluster and it has been unreachable for more than 30 days and that the Cloudera Data Hub cluster’s status is outdated or no longer reflects its current state. For more information, see Cloudera Data Hub status options.

Added get-operation command to obtain operation status
A new command, get-operation is now available to get the status of the latest operation or a specified earlier operation performed on a Cloudera Data Hub cluster. For more information, see Monitoring clusters.

Support for Italy North, New Zealand North, and Poland Central Azure regions
The Italy North, New Zealand North, and Poland Central Azure regions are now supported. You can register Azure environments and provision Cloudera Data Hub clusters in these regions. See updated Supported Azure regions.

Cloudera Data Warehouse

Cloudera Data Warehouse 1.9.6-b2 introduces the following changes:

Fixed issues

DWX-20309: Database Catalog fails to start after upgrading Data Lake to Azure Flexible Server
This fix partially addresses an issue where the Cloudera Data Warehouse Database Catalog fails to start after upgrading the Data Lake from Azure Single Server to Azure Flexible Server. Prior to this fix, you were required to reactivate the Cloudera Data Warehouse environment as a workaround. However, with this fix, you only have to rebuild the Database Catalog and do not have to reactivate the environment.

For more information about the Known issues, see the Cloudera Data Warehouse Release Notes.

Cloudera Management Console

The latest version of Cloudera Management Console introduces the following changes:

Added Stale cluster status
Stale cluster status has been added to the list of cluster statuses to express a status where we have no information from the cluster and it has been unreachable for more than 30 days and that the Data Lake’s status is outdated or no longer reflects its current state. For more information, see Data Lake status options.

Added get-operation command to obtain operation status
A new command, get-operation is now available to get the status of the latest operation or a specified earlier operation performed on an environment or a Data Lake cluster. For more information, see Monitoring a Data Lake, Monitoring an AWS environment, Monitoring an Azure environment, and Monitoring a GCP environment.