Cloudera Docs

Known issues in Cloudera Data Warehouse on premises 1.5.5 SP4

Review the known issues in Cloudera Data Warehouse 1.5.5 Service Pack 4, for service layer version 1.13.0-b81, Hive, Impala, and Hue runtime version 2026.0.21.5-18, and Trino runtime version 2026.0.24.1-10.

Known issues in Cloudera Data Warehouse on premises

DWX-24610: The Impala Virtual Warehouse UI does not show an error when the pre-upgrade backup fails
If the Back up Virtual Warehouse namespaces before an upgrade option is enabled in Advanced Configurations, an Impala Virtual Warehouse runtime upgrade might fail to start if the namespace backup fails or exceeds five minutes. The UI does not display an error message or notification, causing the upgrade to appear stalled.
If the runtime upgrade does not start within five minutes, disable the backup option and retry the upgrade.
  1. In the Cloudera Data Warehouse console, click Advanced Configurations for your environment.
  2. Disable the Back up Virtual Warehouse namespaces before an upgrade option and click Update.
  3. On the Overview page, go to the Environments tab, and select the > Refresh option.
  4. On the Virtual Warehouses tab, locate the affected Impala Virtual Warehouse, refresh it, and restart the runtime upgrade.
DWX-24594: Hive Virtual Warehouse goes to Bad health after a backup timeout during upgrade
When the Back up Virtual Warehouse namespaces before an upgrade option is enabled, Cloudera Data Warehouse backs up the Hive Virtual Warehouse before performing a runtime upgrade. If the backup exceeds the configured timeout period, the upgrade fails with a timeout exceeded for backup error. The Virtual Warehouse then enters a Bad health state instead of reverting to the Stopped state, which prevents you from retrying the upgrade.
To recover the Virtual Warehouse and retry the upgrade without the pre-upgrade backup, perform the following steps:
  1. In the Cloudera Data Warehouse console, click Advanced Configurations for your environment.
  2. Disable the Back up Virtual Warehouse namespaces before an upgrade option and click Update.
  3. On the Overview page, go to the Environments tab, and select the > Refresh option.
  4. On the Virtual Warehouses tab, locate the affected Impala Virtual Warehouse, refresh it, and restart the runtime upgrade.
DWX-24368: Virtual Warehouse remains in the Creating state during embedded database failover
When creating a Virtual Warehouse while the embedded database is undergoing failover to a new primary node, the Virtual Warehouse can remain in the Creating state indefinitely without displaying an error message or status event, even after the database recovers.
Ensure that the embedded database failover process is complete and the cluster is healthy then perform the following steps:
  1. In the Cloudera Data Warehouse console, go to the Overview page.
  2. Click the Virtual Warehouses tab and locate the affected Virtual Warehouse.
  3. Delete the Virtual Warehouse.
  4. Once the database is fully operational, create a new Virtual Warehouse.
DWX-24511: Enabling Istio service mesh introduces query and client latency overhead in Hive Virtual Warehouses
When Istio service mesh is enabled in Cloudera Data Warehouse by setting the istio-mesh-mode property to sidecar or ambient, Hive Virtual Warehouse queries might take 6% to 9% longer to complete. Routing traffic through proxy layers introduces incremental latency to frequent network round trips, such as HiveServer2 compilation, Hive Metastore lookups, and YARN coordination. These delays accumulate, impacting short, metadata-heavy queries the most and long-running queries the least. Ambient mode adds less latency than sidecar mode because it uses a lighter-weight proxy.
To address or reduce the performance overhead, choose one of the following options and perform the configuration procedure:
  • If mutual TLS is required, set sidecar to ambient. This reduces but does not eliminate the overhead.
  • If your security requirements allow unencrypted traffic between components, set the istio-mesh-mode property to "" (an empty string). This removes the overhead completely, but traffic is no longer encrypted with mutual TLS.
Procedure:
  1. Update the istio-mesh-mode property in the edws.yaml key of the cdp-release-dwx-edwsyaml ConfigMap in the Cloudera namespace.
  2. Restart the cdp-release-dwx-server and cdp-release-dwx-worker deployments.
  3. Rebuild all existing Database Catalogs and Virtual Warehouses before running any workloads.
DWX-24510: Query performance degradation in Impala Virtual Warehouses when Istio service mesh is enabled
The Istio service mesh is disabled in Cloudera Data Warehouse by default. This issue applies only when Istio service mesh is enabled by setting the istio-mesh-mode property to sidecar or ambient.

When the mesh is enabled, all traffic between pods is routed through additional proxy layers, adding network latency to communication between Impala components. Impala is more sensitive to this than other engines because its internal communication consists of a high volume of small messages. In sidecar mode, complex queries reading large amounts of data might take up to 2.5 times longer to complete. Under concurrent query workloads, both sidecar and ambient modes add roughly 8% to 10% overhead compared to running without the mesh. Simple or short-running queries are less affected because the added latency is small relative to the total query time.

You can reduce or remove the overhead by changing the mesh mode.
  • Switching from sidecar to ambient reduces the overhead for data-intensive queries because ambient mode uses a lighter-weight proxy, while mutual TLS between components is retained. However, ambient mode still introduces about 8% to 10% overhead during concurrent workloads.
  • Setting the mode to "" (an empty string) removes the overhead entirely, but disables the service mesh for Cloudera Data Warehouse and traffic between components is no longer encrypted by mutual TLS. Choose this only if your security requirements allow it.
Procedure:
  1. Update the istio-mesh-mode property in the edws.yaml key of the cdp-release-dwx-edwsyaml ConfigMap in the Cloudera namespace.
  2. Restart the cdp-release-dwx-server and cdp-release-dwx-worker deployments.
  3. Rebuild all existing Database Catalogs and Virtual Warehouses before running any workloads.
DWX-24476: Impala catalogd and statestored operate in permissive mutual TLS mode under Istio mesh
The Istio service mesh is disabled in Cloudera Data Warehouse by default. This issue applies only when Istio service mesh is enabled by setting the istio-mesh-mode property to sidecar or ambient.
Cloudera Data Warehouse enforces a strict mutual TLS policy on core service components, including the Impala coordinator and executors, HiveServer2, the Hive Metastore, and the Trino coordinator and workers, requiring all incoming connections to be encrypted. However, the following infrastructure components lack a strict policy and operate in permissive mode, accepting both encrypted and unencrypted traffic:
  • Impala catalogd, statestored, admissiond, autoscaler, proxy
  • Hue query processor

During normal operations, inter-component communication to these services remains encrypted because all native Cloudera Data Warehouse components participate in the mesh and automatically upgrade connections to mutual TLS.

The permissive configuration allows unencrypted connections only if an unauthorized workload without sidecar proxy injection is manually deployed directly inside the Virtual Warehouse namespace. Because deploying pods within this namespace requires cluster-level Kubernetes administrative privileges, this issue does not expose data or traffic to standard Cloudera Data Warehouse users.

None
DWX-24584: Log router namespace is not restored during Velero Disaster Recovery Service restore
The log router namespace is not included as part of the Velero Disaster Recovery Service restore process, which prevents proper log routing functionality post-restore.
  1. In the Cloudera Data Warehouse console, click Advanced Configurations.
  2. Clear the Store Logs on HDFS checkbox, and click Update.
  3. On the Overview page, go to the Environments tab, and select the > Refresh option for your environment.
  4. In Advanced Configurations, select the Store Logs on HDFS checkbox, and click Update.
  5. Refresh the environment again by repeating Step 3.
DWX-24573: Virtual Warehouse displays a warning or rejected status after restore
After a Velero restore, a Virtual Warehouse or Database Catalog in the Cloudera Data Warehouse UI might display warning indicators or an application rejected status due to leftover pods from the previous state.
Clean up the remaining pods and update the UI status by performing the following steps:
  1. In the Cloudera Data Warehouse console, go to the Overview page.
  2. Depending on the affected entity, go to either the Virtual Warehouses tab or the Database Catalogs tab.
  3. Locate your affected Virtual Warehouse or Database Catalog.
  4. Select the > Refresh option.
DWX-23995: Cloudera Data Warehouse sidecar containers adopt upgraded Cloudera Data Warehouse version upon Database Catalog or Virtual Warehouse rebuild
Rebuilding a Database Catalog or Virtual Warehouse after upgrading the Cloudera Data Warehouse on updates its sidecar containers to the newly deployed version. However, the underlying runtime workload images, such as metastore, hiveserver2, catalogd, and coordinator, do not update and remain at their pre-rebuild version.

This is expected behavior in version 1.5.5 SP4. Retaining the pre-rebuild workload images ensures that any faulty Virtual Warehouses can recover and rebuild cleanly after a Cloudera Data Warehouse upgrade. Once a Virtual Warehouse is healthy, you can manually upgrade it to the latest image version from the context menu.

None
DWX-24571: Backup and restore jobs fail due to WebHDFS probe and missing Hue database errors
Cloudera Data Warehouse backup and restore jobs embed inline shell scripts that cause operations to fail on secure private cloud clusters. Specifically, active namenode probes using GETCONTENTSUMMARY return an HTTP 403 Forbidden error, and Database Catalog level Hue backup scripts fail when attempting to run pg_dump on non-existent _huedb databases.
Deploy a temporary mutating admission webhook to automatically patch created backup and restore job specifications at runtime. For detailed deployment instructions and scripts, see Cloudera Data Warehouse backup and restore job failures.

Known issues in Cloudera Data Explorer (Hue) on Cloudera Data Warehouse on premises

DWX-24353: Kerberized Oracle catalog navigation panel visibility
In Data Explorer, a successfully configured Kerberized Oracle catalog does not appear in the left navigation panel, even though schema and table queries through Trino succeed. Running SQL commands such as SHOW CATALOGS and SHOW SCHEMAS confirms that the catalog and schemas exist on the Trino engine. Manual browser or UI refreshes do not display the catalog.
None.

Known issues in Hive on Cloudera Data Warehouse on premises

There are no new known issues in this release.

Known issues in Iceberg on Cloudera Data Warehouse on premises

There are no new known issues in this release.

Known issues in Impala on Cloudera Data Warehouse on premises

There are no new known issues in this release.

Known issues in Trino on Cloudera Data Warehouse on premises

DWX-24554: Trino Virtual Warehouse Atlas integration causes message backlog and delays indexing in Cloudera Data Warehouse
When a Trino Virtual Warehouse in Cloudera Data Warehouse is connected to a Cloudera on premises 7.1.9 or 7.3.1, Apache Atlas integration is not supported for Trino. The Trino Virtual Warehouse sends trino_* entity messages that the base cluster's Atlas service cannot process. This creates a message backlog that slows down Atlas processing and delays metadata indexing for Hive and Impala in Cloudera Data Warehouse.
Disable the Trino Atlas plugin on the Trino Virtual Warehouse:
  1. Log in to the Cloudera Data Warehouse service as DWAdmin.
  2. Go to the Virtual Warehouses tab.
  3. Locate the Virtual Warehouse and click > Details .
  4. Click the Configurations tab.
  5. In the left navigation pane, select Trino Coordinator.
  6. From the Configuration file drop-down menu, choose trino-atlas-event-config.
  7. Delete the key atlas.trino.catalogs.registered, and click Apply Changes.
DWX-24572: Trino Virtual Warehouse rebuild fails after Velero restore
After performing a Velero restore in Cloudera Data Warehouse, attempting to rebuild a Trino Virtual Warehouse might intermittently fail with one of the following errors:
  • failed to rebuild Virtual Warehouse Trino (<trino-vw-id>) (cause: activity failed: unable to delete namespace. err: deleting namespace '<trino-vw-id>': failed to delete the resource pool '...')

  • failed to rebuild Virtual Warehouse Trino (<trino-vw-id>) (cause: configuring: internal CDW error (cause: couldn't find ldap.xml))
Initiate a second Rebuild operation on the affected Trino Virtual Warehouse:
  1. In the Cloudera Data Warehouse console, go to the Overview page.
  2. In the Virtual Warehouses tab, locate your affected Trino Virtual Warehouse.
  3. Click the > Rebuild option.

    The rebuild successfully cleans up the remaining resources, generates the required configuration files, and brings the Trino Virtual Warehouse into a running state.