General known issues
This topic describes the general platform-wide known issues for Cloudera Data Warehouse (CDW) Private Cloud.
- DWX-10403: Executor pods get stuck in pending state with a warning
- In rare circumstances, when Impala or Hive executors start up either due to autoscaling or by manually restarting the executors, the pods may get stuck in a pending state with a warning such as "volume node affinity conflict". This happens due to a race condition in the storage class that provides local volumes.
- Restart the pods so that they can be rescheduled on new nodes with enough resources.
- DWX-8525 and DWX-8526: CDW does not support upgrades from CDW 1.2 to 1.3.2
- You may encounter issues while creating a new Virtual Warehouse on an existing Database Catalog (version 1.2) in an environment that is upgraded from 1.2 to 1.3.1.
- The existing Virtual Warehouses will continue to operate. But if you want to create a new Virtual Warehouse, then you must reactivate the CDW environment after upgrading the base cluster from 1.2 to 1.3.2.
- DWX-8502: HMS health check does not check port 9083
- The HMS health check script does not check the health of its service port 9083 and may provide incorrect health status.
- DOCS-7431: LDAP limitations in CDW Private Cloud Virtual Warehouses
- CDW Private Cloud workloads in Hive, Impala, Hue, and Data Analytics Studio (DAS) use simple bind authentication without filters. However, Management Console control plane uses search bind.
- CDW Workloads use the LDAP Bind User field as the user bind pattern after replacing the user name with the pattern string. The workload users should be under the same sub-tree as the LDAP bind user.
- DWX-5496: If Cloudera Manager truststore or the external database/vault is updated, CDW environment activation fails
- Problem:If you have activated environments in CDW Private Cloud 1.1
and you update the Cloudera Manager truststore or the external database/vault truststore,
you must update all of your CDW Private Cloud components else environment activation fails
in CDW Private Cloud 1.1.
For example, you might perform truststore updates for the following use cases:
- To rotate the database certificate.
- To add a new CA certificate for a secure connection to an external vault.
- To rotate the Cloudera Manager certificate.
For information about these tasks, see Updating TLS certificates in the Management Console documentation set.
- If any of these scenarios apply to your deployment, perform
the following steps to make sure you can activate CDW environments for Database Catalogs
and Virtual Warehouses in CDW Private Cloud 1.1:
- In CDW Private Cloud 1.1, delete or remove all existing Virtual Warehouses.
- Back up all the corresponding metadata or DDL to ensure you can recreate the objects contained in your Database Catalogs. Also back up your table data.
- Delete or remove all existing Database Catalogs except the default Database Catalogs.
- Deactivate the environment in CDW. To deactivate an environment, navigate to the environment tile and click the deactivate icon . Follow the prompts to deactivate the environment.
- Update the certificate in the Management Console UI.
- In the CDW UI, reactivate the environment.
- Recreate the non-default Database Catalogs.
- Recreate the Virtual Warehouses.
After you perform these steps, you can use your Virtual Warehouses with the updated truststore. For more information about managing SSL-enabled client endpoints in CDW Private Cloud, see SSL-enabled client endpoints.
- DWX-5129: Management Console and CDW service workloads must reside in the same OpenShift cluster
- If Management Console and the CDW service workload reside on two different OpenShift clusters, the workload fails.
- During environment registration in Management Console, ensure that you point to the same OpenShift cluster as you did during installation.