General known issues
This topic describes the general platform-wide known issues for Cloudera Data Warehouse (CDW) Private Cloud.
- 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 or 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 as explained in Update a CA certificate for a secure database connection.
- To add a new CA certificate for a secure connection to an external vault as explained in Update a CA certificate for a secure vault connection.
- To rotate the Cloudera Manager certificate as explained in Update a CA certificate for a secure Cloudera Manager connection.
- 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-5941: Custom service accounts are not supported in CDW Private Cloud 1.1
- Problem: CDP Private Cloud uses a set of default names for service accounts.
spark. You can overwrite these default service account names during the Cloudera Manager installation of CDP Private Cloud 1.1. However, Cloudera Data Warehouse (CDW) experience in CDP Private Cloud 1.1 does not support custom service account names. If custom service account names are used, activation of environments for CDW fails, creation of the default Database Catalog fails, and no Virtual Warehouses will start.
- Workaround: Be sure to accept default service account names when you install CDP Private Cloud 1.1 Base Cluster with Cloudera Manager.
- DWX-5091: SSL-enabled PostgreSQL database required for Hive Metastore on the CDP base cluster on the Cloudera Manager side
The database that is used for the Hive Metastore on the base CDP cluster (Cloudera Manager side) must be PostgreSQL, and 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 will fail.
- Workaround: Ensure during environment registration in Management Console that you point to the same OpenShift cluster as you did during installation.