Fixed Issues

Review the list of Cloudera Manager issues that are resolved in Cloudera Manager 7.13.3 and its cumulative hotfixes.

Cloudera Manager 7.13.3 resolves issues and incorporates fixes from the cumulative hotfixes from 7.13.2.100 through 7.13.2.20000. For a comprehensive record of all fixes in Cloudera Manager 7.13.2.x, see Fixed Issues 7.13.2.x.

Cloudera Manager 7.13.3.0

OPSAPS-79698: ATLAS is not accessible for GCP cluster with LIGHT_DUTY_WITHOUT_HBASE
7.13.2.30000
Previously, when database SSL was enabled for Atlas on a GCP cluster using PostgreSQL RDS, Cloudera Manager configured the JanusGraph JDBC URL with sslmode=verify-full. This caused hostname verification to fail because only an IP address was available, preventing Atlas from starting. This issue is now resolved. When atlas.db.ssl.verifyServerCertificate is true and atlas.db.ssl.certificateFile is set, Cloudera Manager uses sslmode=verify-ca instead.
OPSAPS-81307: Ozone refresh cluster command fails due to missing Kerberos configuration
7.13.3.0
Previously, the Ozone refresh cluster command failed in Kerberos-enabled environments because the refresh handlers did not include the moveConfigs operation. This caused the Ozone client to fall back to simple authentication, which resulted in access control errors. This issue is now resolved by adding the moveConfigs operation to all Ozone refresh handlers, which ensured that the necessary Kerberos settings were correctly applied during a cluster refresh.
OPSAPS-76171: Cloudera Manager skips the INVALIDATE METADATA step when an Impala Daemon reports a warning status
7.13.3.0

Previously, during Hive external table replication with Replication Manager, Cloudera Manager silently skipped the INVALIDATE METADATA step if an Impala Daemon reported any health test warning, such as an upcoming certificate expiration. Cloudera Manager did not run the command and did not provide an explanation in the command history or server logs.

This issue is now resolved by introducing the Impala Health Threshold For Skipping Invalidate Metadata setting. The default value is now Red, which skips metadata invalidation only when an Impala Daemon experiences a critical failure. Health test warnings no longer prevent Cloudera Manager from executing the step. When Cloudera Manager skips the step, it documents the reason in the command history and records the event in the Cloudera Manager server log.

OPSAPS-78574, OPSAPS-80536: Cloudera Manager skips scheduled commands when the scheduler is unavailable or overloaded
7.13.3.0

Previously, Cloudera Manager omitted scheduled commands (such as replication policies and snapshot policies) when administrators scheduled more than approximately 30 commands to run simultaneously. Because Cloudera Manager initiated commands sequentially within a single minute, commands that could not start within that minute failed to run. Additionally, when Cloudera Manager shut down or heavy workloads overloaded the scheduler during a scheduled execution window, the scheduler skipped those commands entirely and did not execute them later.

Cloudera Manager now triggers missed commands immediately when the scheduler becomes available. Even if an outage or period of heavy load spans multiple scheduled intervals, Cloudera Manager triggers only a single execution upon recovery. For example, if you schedule a command to run every two hours, and the scheduler remains unavailable for seven hours, Cloudera Manager executes that command once immediately when the scheduler recovers, and runs the subsequent execution at its next regular scheduled time. This issue is now resolved by setting the scheduler misfire policy to FIRE_ONCE_NOW by default.

OPSAPS-79524: Improved Replications page performance when loading Hive ACID policies
7.13.3.0

Previously, the Replications page took more than a minute to load in environments with more than 100 Apache Hive ACID policies. For each Hive ACID policy, the service issued two sequential remote calls to the source, which slowed down the page load time for all policies.

This issue is now resolved by consolidating the queries into a single remote call per source. The Replications page now loads faster without initiating multiple remote calls per policy.