Known Issues in Cloudera Manager 7.11.3 Cumulative hotfix 1 for Data Services 1.5.2

OPSAPS-68452: Azul Open JDK 8 and 11 are not supported with Cloudera Manager

Azul Open JDK 8 and 11 are not supported with Cloudera Manager. To use Azul Open JDK 8 or 11 for Cloudera Manager RPM/DEBs, you must manually create a symlink between the Zulu JDK installation path and the default JDK path.

After installing Azul Open JDK8 or 11, you must run the following commands on all the hosts in the cluster:

Azul Open JDK 8

RHEL or SLES

# sudo ln -s /usr/lib/jvm/java-8-zulu-openjdk-jdk /usr/lib/jvm/java-8-openjdk

Ubuntu or Debian

# sudo ln -s /usr/lib/jvm/zulu-8-amd64 /usr/lib/jvm/java-8-openjdk

Azul Open JDK 11

For DEBs only

# sudo ln -s /usr/lib/jvm/zulu-11-amd64 /usr/lib/jvm/java-11

OPSAPS-68558: Cloudera Manager upgrade fails with the following error:There are 1 active commands of type GetClientConfigFiles

After upgrading from Cloudera Manager 7.9.5 to 7.11.3.2 version, the Cloudera Manager server does not start. Cloudera Manager server log displays an error about active commands. This scenario might occur when the Private Cloud Data Service Control Plane is actively issuing requests to Cloudera Manager while performing an upgrade.

Before Cloudera Manager upgrade make sure there are no active commands such as getClientConfig. If there are any active commands, then allow them to complete before kicking off the Cloudera Manager upgrade process.

Post upgrade, inspect the Cloudera Manager server log for the following error message: There are 1 active commands of type GetClientConfigFiles. This error might block Cloudera Manager to restart after the upgrade process. If Cloudera Manager restart fails due to the presence of active getClientConfig command, then to resolve this issue, perform the following steps:

Login to Cloudera Manager database.

Search for any active GetClientConfigFiles command in COMMANDS table.

SELECT NAME, ACTIVE  , COMMAND_ID FROM COMMANDS WHERE ACTIVE <> 0 AND NAME='GetClientConfigFiles';

Update the entry for the command_id found in step 2.

UPDATE COMMANDS SET active=0,success=false,state='CANCELLED' where command_id=<command_id>;

Restart the Cloudera Manager server by running the following command:
```
sudo systemctl restart cloudera-scm-server
```

OPSX-2713: ECS Installation: Failed to perform First Run of services.

If an issue is encountered during the Install Control Plane step of Containerized Cluster First Run, installation will be re-attempted infinitely rather than the command failing.

Since the control plane is installed and uninstalled in a continuous cycle, it is often possible to address the cause of the failure while the command is still running, at which point the next attempted installation should succeed. If this is not successful, abort the First Run command, delete the Containerized Cluster, address the cause of the failure, and retry from the beginning of the Add Cluster wizard. Any nodes that are re-used must be cleaned before re-attempting installation.

OPSX-735: Kerberos service should handle Cloudera Manager downtime

The Cloudera Manager Server in the base cluster must be running in order to generate Kerberos principals for Private Cloud. If there is downtime, you may observe Kerberos-related errors.

Resolve downtime on Cloudera Manager. If you encounter Kerberos errors, you can retry the operation (such as retrying creation of the Virtual Warehouse).

OPSAPS-69481: Some Kafka Connect metrics missing from Cloudera Manager due to conflicting definitions

The metric definitions for kafka_connect_connector_task_metrics_batch_size_avg and kafka_connect_connector_task_metrics_batch_size_max in recent Kafka CSDs conflict with previous definitions in other CSDs. This prevents CM from registering these metrics. It also results in SMM returning an error. The metrics also cannot be monitored in CM chart builder or queried using the CM API.

Contact Cloudera support for a workaround.