General known issues
This topic describes the general platform-wide known issues for Cloudera Data Warehouse (CDW) Private Cloud.
- DWX-8525 and DWX-8526: CDW does not support upgrades from CDW 1.2 to 1.3.1
- Problem: 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.
- Workaround: 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.1.
- DWX-8517: Default Database Catalogs fail to start on ECS cluster with MySQL database
- Problem: CDW does not support MySQL as a database for HMS on the base cluster.
- Workaround: None.
- DWX-8510: Unable to enforce group Ranger policy for CDW services
- Problem: The CDW services cannot enforce group Ranger policies, which means that group based access control is not enforced currently.
- Workaround: Use user policies instead.
- DWX-8502: HMS health check does not check port 9083
- Problem: The HMS health check script does not check the health of its service port 9083 and may provide incorrect health status.
- Workaround: None.
- DWX-6736: Ranger KMS on the CDP base cluster not supported
- Problem: Queries fail on Hive Virtual Warehouses if the CDP Base cluster contains Ranger KMS.
- Workaround: None available.
- DOCS-7431: LDAP limitations in CDW Private Cloud Virtual Warehouses
- Problem: 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.
- Workaround: 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.
- Workaround: 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 in CDW Private Cloud 1.1 with the updated truststore. For more information about managing SSL-enabled client endpoints in CDW Private Cloud, see SSL-enabled client endpoints.
- DWX-5091: SSL-enabled PostgreSQL database required for Hive Metastore on the CDP base cluster on the Cloudera Manager side
If you are using PostgreSQL database for the Hive Metastore on the base cluster, then it must meet the following requirements::
To use the same keystore with embedded certificate for Ranger and Atlas:
- Uses the same keystore containing an embedded certificate as Ranger and Atlas uses.
- If you are using Auto-TLS:
In the Management Console Administration page, navigate toand add the certificate name (for example,
/path/to/postgres.pem) in the Trusted CA Certificate option.
- If you are not using Auto-TLS:
Ensure that the public certificate of the certificate authority (CA) that signed the Hive metastore database's certificate is present in Cloudera Manager's JKS truststore. If the certificate is self-signed, import that certificate into Cloudera Manager's JKS truststore: In the Management Console Administration page, find the path to Cloudera Manager's JKS truststore by navigating to. Import the CA's certificate into that JKS file.
To add the certificate name to an existing or a new JKS file, use the following
keytoolcommand, which uses the same example certificate name:
keytool -import -alias postgres -file /path/to/postgres.pem -storetype JKS -keystore /path/to/cm.jks
/path/to/cm.jksis the JKS file that is configured by Cloudera Manager.
This ensures that the file specified for Cloudera Manager TLS/SSL Client Trust Store File is passed to Management Console and workloads.
- DWX-5129: Management Console and CDW service workloads must reside in the same OpenShift cluster
- Problem: If Management Console and the CDW service workload reside on two different OpenShift clusters, the workload fails.
- Workaround: During environment registration in Management Console, ensure that you point to the same OpenShift cluster as you did during installation.