Known Issues in Cloudera Manager 7.7.1

Known issues in Cloudera Manager 7.7.1

Cloudera bug: OPSAPS-64029
When Cloudera Manager is upgraded from prior versions to 7.7.1 or later, Queue Manager (QM) will be flagged as stale due to new support for auto-configuration of QM with Yarn Resource Manager (RM).
Restart the QM role at a convenient time.
Cloudera bug: OPSAPS-63881: When CDP Private Cloud Base is running on RHEL/CentOS/Oracle Linux 8.4, services fail to start because service directories under the /var/lib directory are created with 700 permission instead of 755.
Run the following command on all managed hosts to change the permissions to 755. Run the command for each directory under /var/lib:
chmod -R 755 [***path_to_service_dir***]
x
Cloudera Bug: OPSAPS-63838: Cloudera Manager is unavailable after failover
When high availability is enabled for Cloudera Manager, and there is a failover from the Active to the Passive server, the Cloudera Manager server may be unavailable for 15-20 seconds when failing back to the Active server.

Known Issues in Replication Manager

OPSAPS-64388 - Schedule creation API doesn't stop user from creating a bucket within a bucket
When the bucket path in the source and target clusters are different, the replication policy creation API does not fail but the Ozone replication fails with the Ozone File Listing Command Failed error.
Before you create the Ozone replication policy using Cloudera Manager APIs, ensure that the path of the bucket which includes the volume name and bucket name in the target cluster is same as in the source cluster.
OPSAPS-64466 - JCKS way of authentication on Ozone causes YARN to go down on Auto-TLS cluster
During the Ozone replication policy job for OBS buckets, the YARN application goes down and does not restart when the authentication credentials for Auto-TLS is provided using the hadoop.security.credential.provider.path property where the value is the JKS file.
Configure fs.s3a.secret.key and fs.s3a.access.key in the Ozone Client Advanced Configuration Snippet (Safety Valve) property in the ozone-conf.xml and ozone-site.xml files so that the Ozone replication policies use the authentication credentials in these files for OBS bucket replication.
OPSAPS-64501 - Hive 3 replication | CMHA | Failover doesn't go to completion status on its own
This behavior is observed when high availability is enabled for both source and target clusters’ Cloudera Manager instances.

When you click Actions > Start Failover for a successful Hive ACID table replication policy on the Replication Policies page, the policy job does not transition to failover status for a long time. When you click Actions > Revert/Complete failover for the same replication policy, the policy transitions to failover complete and then eventually disables the policy.