General known issues

This topic describes the general platform-wide known issues for Cloudera Data Warehouse (CDW) Private Cloud.

DWX-7301: LDAP Group Sync is not supported by CDW Private Cloud 1.2
Problem: Ranger group-based policies are not supported by CDW because the LDAP group mappings cannot be fetched by CDW.
Workaround: None available.
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 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.
  • 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:
  1. In CDW Private Cloud 1.1, delete or remove all existing Virtual Warehouses.
  2. 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.
  3. Delete or remove all existing Database Catalogs except the default Database Catalogs.
  4. 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.
  5. Update the certificate in the Management Console UI.
  6. In the CDW UI, reactivate the environment.
  7. Recreate the non-default Database Catalogs.
  8. 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
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:
  • SSL-enabled.
  • Uses the same keystore containing an embedded certificate as Ranger and Atlas uses.
To use the same keystore with embedded certificate for Ranger and Atlas:
  • If you are using Auto-TLS:

    In the Management Console Administration page, navigate to Security > Enable Auto-TLS and 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 Administration > Settings > Security > Cloudera Manager TLS/SSL Client Trust Store File. 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 keytool command, which uses the same example certificate name:

    keytool -import -alias postgres -file /path/to/postgres.pem -storetype JKS -keystore /path/to/cm.jks

    Where /path/to/cm.jks is 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.