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.