Upgrade-related known issues

This topic describes the upgrade-related known issues for Cloudera Data Warehouse (CDW) Private Cloud.

DWX-8525 and DWX-8526: CDW supports upgrades from previous releases to 1.5.0 release with listed limitations: You may encounter issues while creating a new Virtual Warehouse on an existing Database Catalog (for example version 1.4.1) in an environment that is upgraded from, say 1.4.1 to 1.5.0.; The existing Virtual Warehouses continue to operate. But to create a new Virtual Warehouse, you must reactivate the CDW environment after upgrading the Private Cloud data services from a previous release to a newer release (for example from 1.4.1 to 1.5.0.)
important
Review the following caveats before upgrading to 1.5.0:

Reactivating the environment deletes the existing Database Catalogs and Virtual Warehouses. However, the metadata stored in the Hive Metastore (HMS) and data that is stored on HDFS or Ozone from the previous version is not deleted from the base cluster. Cloudera recommends that you manually take a backup of the Virtual Warehouse configurations, which you can use to create new Virtual Warehouses after the upgrade.

(For ECS) On ECS, a “default” environment is created by the Control Plane when you add a Private Cloud cluster. If you have more than one ECS clusters managed using different instances of Cloudera manager, but using the same Active Directory (AD) server and using the same “default” environment, then go to the Advanced Configuration > Advanced Settings page and disable the Use deterministic namespace names option after performing the upgrade but before reactivating the environment in CDW.
If you did not use the default environment which is created in CDW, then you can create a new environment from Management Console with a unique name.

(For OCP) If you have more than one OCP clusters managed using different instances of Cloudera Manager, but using the same AD server and using the same environment name, then go to the Advanced Configuration > Advanced Settings page and disable the Use deterministic namespace names option after performing the upgrade but before reactivating the environment in CDW.
If you are creating a new environment from the Management Console with a unique name, then you need not disable the Use deterministic namespace names option.

Apply workaround for the AD limitation (TSB-639): If Cloudera Manager does not manage the /etc/kerb5.conf file, then add the following lines in the /etc/kerb5.conf file manually to every host in the cluster:
[libdefaults] allow_weak_crypto = true
DWX-14192: Atlas entities not created after upgrading from 1.4.0-H1 to 1.5.0: After upgrading from 1.4.0-H1 to 1.5.0, you may notice that Atlas entities are not created and you may see the following error in the metastore pod logs: java.security.UnrecoverableKeyException: Password verification failed; Log in to the Data Warehouse service as DWAdmin.

Go to the Database Catalog tile and note the Database Catalog namespace.

Get the Kubernetes configuration for accessing the cluster using the kubectl command.
For OCP, see Downloading the Kubernetes Configuration.
On ECS deployments, log into the nodes as a root user. Login into the master node, which is usually the first node, and check access to the cluster with the following kubectl command:
/var/lib/rancher/rke2/bin/kubectl --kubeconfig=/etc/rancher/rke2/rke2.yaml get nodes
note
On ECS, run the /var/lib/rancher/rke2/bin/kubectl command on the node you accessed in the SSH session, and use the /etc/rancher/rke2/rke2.yaml kubeconfig file in the next steps.

Run the following command to get the jceks-secret:
kubectl get secret jceks-secret -n [***DBC-NAMESPACE***] -o yaml --kubeconfig=/path/to/kubeconfig

Create a backup of the jceks-secret file as follows:
kubectl get secret jceks-secret -n [***DBC-NAMESPACE***] -o yaml --kubeconfig=/path/to/kubeconfig > jceks-secret.backup.yaml

Verify that the contents of the backup file are same as the original file as follows:
cat ./jceks-secret.backup.yaml

Save the jceks-secret.backup.yaml file.

Create a new jceks-secret file with the updated password while specifying the “metastore-0” pod as follows:
kubectl exec -it metastore-0 -n [***DBC-NAMESPACE***] --kubeconfig=/path/to/kubeconfig -- /bin/bash -c "cp /jceks/secrets.jceks /tmp/ && hadoop credential delete truststore.password -provider jceks://file/tmp/secrets.jceks -f && hadoop credential create truststore.password -value changeit -provider jceks://file/tmp/secrets.jceks && cat /tmp/secrets.jceks | base64 -w 0 > /tmp/secrets.jceks.b64 && hadoop fs -rm file:///tmp/secrets.jceks"
This creates a copy of the secrets.jceks file, removes the truststore.password key from the tmp/secrets.jceks file, creates a new /tmp/secrets.jceks.b64 file on the filesystem of the metastore-0 pod, and finally removes the /tmp/secrets.jceks file from the filesystem of the metastore-0 pod.
The /tmp/secrets.jceks.b64 file is used for creating a patch file in the next step.

Create a patch file as follows:
echo "data:" > jceks-secret.patch.yaml && echo -n " secrets.jceks: " >> jceks-secret.patch.yaml
The jceks-secret.patch.yaml patch file is required for modifying the jceks secret that is stored in the Kubernetes environment.

Run the following command to append data from the /tmp/secrets.jceks.b64 file (present on the metastore-0 pod) to the jceks-secret.patch.yaml file (present on the local filesystem):
kubectl exec -it metastore-0 -n [***DBC-NAMESPACE***] --kubeconfig=/path/to/kubeconfig -- /bin/bash -c "cat /tmp/secrets.jceks.b64" >> jceks-secret.patch.yaml

Verify the contents of the jceks-secret.patch.yaml file as follows:
cat jceks-secret.patch.yaml

Apply the patch as follows:
kubectl patch secret jceks-secret -n [***DBC-NAMESPACE***] --kubeconfig=/path/to/kubeconfig --patch-file ./jceks-secret.patch.yaml

Restart the metastore pods as follows:
kubectl delete pod metastore-0 -n [***DBC-NAMESPACE***] --kubeconfig=/path/to/kubeconfig
kubectl delete pod metastore-1 -n [***DBC-NAMESPACE***] --kubeconfig=/path/to/kubeconfig