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.
important
Backup of corresponding metadata or DDL is mandatory for custom Database Catalogs, but it is also highly recommended for the default Database Catalog as well.
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. For example, hive, hdfs, and 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:

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.
note
If you have a JRE11 keystore you must convert it to a JRE8 keystore using the following keytool command:
```
keytool -importkeystore -srckeystore
             <path-to-my-pfx-file.pfx> -srcstoretype pkcs12 -srcstorepass
                <***password***>  -destkeystore
                <path-to-client-certificate.jks> -deststoretype JKS
                -deststorepass <***password***>
```

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.