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 setting and click Update.
  3. In the Overview page, go to the Environments tab, click 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 timeout limit, 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, follow these step:
  1. In the Cloudera Data Warehouse console, click Advanced Configurations for your environment.
  2. Disable the Back up Virtual Warehouse namespaces before an upgrade setting and click Update.
  3. In the Overview page, go to the Environments tab, click 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 events, even after the database recovers.
Before performing these steps, ensure that the embedded database failover process is complete and the cluster is healthy.
  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 adds small delays 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, you can choose one of the following options and follow the configuration steps below:
  • If mutual TLS is required, switching from sidecar to ambient reduces but does not eliminate the overhead.
  • If your security requirements allow unencrypted traffic between components, set the istio-mesh-mode property to "" (empty) to remove the overhead completely, though traffic will no longer be encrypted by mutual TLS.
To change the mode:
  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 you run any workload on them, as running workloads before every item is rebuilt can result in communication failures between a Virtual Warehouse and its Database Catalog due to mismatched mesh configurations.
DWX-24510: Query performance degradation in Impala Virtual Warehouses when Istio service mesh is enabled
The Istio service mesh is disabled for Cloudera Data Warehouse by default. This issue applies only if you have explicitly enabled it 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 may 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 affected much less because the added latency is small relative to 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 roughly 8% to 10% overhead during concurrent workloads.
  • Setting the mode to "" (empty) removes the overhead entirely, but this 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.
    To apply the change, update the istio-mesh-mode property in the edws.yaml key of the cdp-release-dwx-edwsyaml ConfigMap in the Cloudera namespace, then restart the cdp-release-dwx-server and cdp-release-dwx-worker deployments.
DWX-24476: Impala catalogd and statestored operate in permissive mTLS mode under Istio mesh
The Istio service mesh is disabled for Cloudera Data Warehouse by default. This issue applies only if Istio service mesh is explicitly enabled by setting the istio-mesh-mode property to sidecar or ambient.
Cloudera Data Warehouse enforces a strict mutual TLS, or mTLS, policy on its main service components, including the Impala coordinator and executors, HiveServer2, the Hive Metastore, and the Trino coordinator and workers, requiring all incoming connections to be mTLS-encrypted. However, the following infrastructure components do not currently have an explicit strict policy applied and instead fall back to 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 mTLS.

The current permissive configuration only allows unencrypted connections if an unauthorized workload without sidecar proxy injection is manually deployed directly inside the Virtual Warehouse namespace. Since 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 DRS restore
The log router namespace is not included as part of the Velero DRS restore process, which prevents proper log routing functionality post-restore.
Perform these steps:
  1. In the Cloudera Data Warehouse console, click Advanced Configurations.
  2. Disable the Store Logs on HDFS check box, and click Update.
  3. In the Overview page, go to the Environments tab, click the > Refresh option for your environment.
  4. In the Advanced Configurations, select the Store Logs on HDFS check box, 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.
Performing these steps will clean up the remaining pods and update the UI status:
  1. In the Cloudera Data Warehouse console, go to the Overview page.
  2. Depending on the affected entity, navigate to either the Virtual Warehouses tab or the Database Catalogs tab.
  3. Locate your affected Virtual Warehouse or Database Catalog.
  4. Click > 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

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.