November 21, 2025

What's new in Cloudera Data Warehouse on cloud

Review the new features introduced in this release of Cloudera Data Warehouse service on Cloudera on cloud.

What's new in Cloudera Data Warehouse on cloud

AWS EKS 1.33 upgrade
Cloudera supports AWS Elastic Kubernetes Service (EKS) 1.33. In 1.11.2-b383 (released November 21, 2025), when you activate an Environment, Cloudera Data Warehouse automatically provisions EKS 1.33. To upgrade to EKS 1.33 from a lower version of Cloudera Data Warehouse, you must backup and restore Cloudera Data Warehouse.

Fixed issues

Review the fixed issues in this release of the Cloudera Data Warehouse service on cloud.

DWX-21607: Nondeterministic hostname resolution during pod startup with multiple services
Previously, when a pod started with multiple services, Kubernetes registered DNS entries for those services, leading to a race condition during startup. This caused the hostname returned by hostname --fqdn to be nondeterministic. For example, the Catalogd container, which normally identified itself as catalogd-0.catalogd-headless.impala-1729924328-8656.svc.cluster.local, instead reported as catalogd-0.impala-1729924328-8656.svc.cluster.local. This mismatch caused the Impala Catalog Server High Availability (HA) implementation to misinterpret the number of Catalogd instances, leading to instability.

This issue is now resolved, and the hostname is now deterministic and statically assigned for Impala containers.

DWX-22191: Improved session routing in Impala-proxy
Previously, the Impala-proxy determined which coordinator is expected to handle new session requests by counting all open HiveServer2 (HS2) sessions on each coordinator, including those without active client connections. This approach led to situations in which the proxy blocked new client connections even when many existing sessions were idle. Consequently, coordinators with several open but inactive sessions were marked as fully loaded, causing reduced availability.

This issue is now resolved. The Impala-proxy now checks only the number of sessions currently in use, which are sessions with active client connections, when making routing decisions. Additionally, users can disable this session-based check entirely by setting the coordinator-load-based-routing CPU and memory weights to 0 in the Impala-proxy configurations. This ensures that routing decisions are based on actual load, preventing unnecessary blocking and improving connection availability.

DWX-22192: Fixed incorrect truststore path for Catalogd in Chainguard images
Previously, the truststore location path for Catalogd in migrated Chainguard images was set incorrectly to /etc/pki/ca-trust/extracted/java/cacerts. This misconfiguration was present in the xasecure.policymgr.clientssl.truststore configuration item in hive-ranger-policymgr. As a result, all Ranger plugin statements, such as GRANT or Revoke, which depend on the trustore for secure communication with the Ranger Admin failed with the following error:
InternalException: Error granting a privilege in Ranger. Ranger error message: unknown error during grantAccess. serviceName=cm_hive.

This issue is now resolved.

CDPD-91992: Impala crashes when writing multiple delete files per partition in a single DELETE operation
Impala queries might crash during a DELETE operation that requires writing multiple delete files to the same partition. This issue was caused by a state management conflict.
The issue has now been resolved, and queries execute successfully without crashes.

Apache Jira: IMPALA-14496

DWX-2219: Compactions no longer stuck in the ready for cleaning stage
Compaction metadata cleanup was broken for non-partitioned tables because PostgreSQL requires an explicit SQL type for every NULL parameter (i.e. partition).
This issue is resolved by addressing the underlying database exceptions that prevented the compaction cleaner from completing its operation and moving past the ready for cleaning stage.
CDPD-68779: Error while browsing S3 buckets or ADLS containers from the left-assist panel
Previously, when attempting to browse S3 buckets or ADLS containers from the left-assist panel in Hue without the required permissions, the system displayed a generic error message: Failed to retrieve buckets:1:0: syntax error This is now fixed. When RAZ is enabled, the left-assist panel now opens the home directory if the required permissions are available. In non-RAZ environments, the left-assist panel opens the path configured in the Hue configuration file.

Known issues

Review the known issues in this release of the Cloudera Data Warehouse on cloud service.

DWX-22178: Virtual warehouse t-shirt size change does not update related configurations
When changing the t-shirt size of a virtual warehouse, for example, from xsmall to small, the related configurations values do not automatically update to match the new t-shirt size. This mismatch can cause the queries to be planned with an incorrect number of executors, potentially leading to suboptimal query execution, resource allocation issues, and degraded performance. The issue arises because the linkage between the t-shirt size setting and the related configurations is missing or not triggered during updates.
After changing the t-shirt size, manually run the Rebuild operation.
DWX-21853: Database Catalog chart installation failure - Istio webhook EOF error
When creating a Data Warehouse cluster on Azure, the deployment process fails during the installation of the Database Catalog charts due to the following internal error related to the Istio validation webhook:
failed calling webhook "validation.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/validate?timeout=10s": EOF

This End of File (EOF) error suggests a network or communication issue in which the connection to the Istio validation service (istiod.istio-system.svc:443) is prematurely closed or is incomplete. The failure prevents the successful creation and activation of the Data Warehouse cluster.

If Database Catalog creation fails with this error, retry the operation. In most cases, a subsequent attempt will succeed. If repeated failures occur, you must retry environment activation or rebuild the Database Catalog or virtual warehouse to resolve the issue.