You can review the changes in certain features or functionalities of Cloudera Manager that have resulted in a change in behavior from the previously
released version to this version of Cloudera Manager 7.13.3.
Cloudera Manager 7.13.3 introduces functional adjustments, behavioral
updates, and includes all cumulative hotfixes from 7.13.2.100 through 7.13.2.20000. For a
comprehensive record of all functional adjustments in Cloudera Manager
7.13.2.x, see Behavioral Changes 7.13.2.x.
Cloudera Manager 7.13.3.0
Summary: Cloudera Manager updates the
health threshold and visibility for skipping the INVALIDATE
METADATA step during Hive external table replication
Starting in Cloudera Manager 7.13.3.0, Cloudera Manager updates how it evaluates Impala Daemon health when
deciding whether to execute the INVALIDATE METADATA step during
Hive external table replication with Replication Manager. Previously, Cloudera Manager skipped this step whenever an Impala Daemon
reported any warning, even when the daemon remained operational. This behavior
caused out-of-synchronization Impala metadata and occurred without explanatory
status updates or log messages.
To prevent unnecessary skips while maintaining cluster stability, Cloudera Manager introduces the Impala Health Threshold
For Skipping Invalidate Metadata parameter. The default threshold is
now less strict (Red), which allows metadata invalidation to run when daemons report
minor warnings. Additionally, Cloudera Manager now logs the
specific reason whenever it skips this step and displays the cause on the command
details page.
Previous behavior:
In Cloudera Manager versions earlier than 7.13.3.0, during Hive
external table replication with Replication Manager, Cloudera Manager skipped the INVALIDATE METADATA
step if any health check on the destination Impala Daemons generated a warning
status or worse. Cloudera Manager skipped the step silently
without recording the reason in the command execution history or the Cloudera Manager server logs.
New behavior:
Starting in Cloudera Manager 7.13.3.0, the new Impala Health
Threshold For Skipping Invalidate Metadata configuration parameter
controls when the INVALIDATE METADATA step runs.
The
parameter supports the following values:
Red: (Default) Cloudera Manager skips the step
only if an Impala Daemon reports a bad or critical health state. Health check
warnings do not prevent the step from running.
Yellow: Cloudera Manager skips the step if an
Impala Daemon reports any warning or critical health state. This option
preserves the previous behavior.
None: Cloudera Manager always runs the step
regardless of the Impala Daemon health state.
When Cloudera Manager skips the INVALIDATE
METADATA step, it adds an explanatory message to the command execution
details and records the reason in the Cloudera Manager server
log.
Summary: Cloudera Manager upgrades the
internal logging framework to Apache Log4j 2
In Cloudera Manager 7.13.3.0, the logging framework transitions from Reload4J (a
Log4j 1 fork) to Apache Log4j 2. Cloudera Manager continues to utilize Simple
Logging Facade for Java (SLF4J) for log routing but replaces the active
configuration file path and format. Existing custom logging configurations do not
migrate automatically to the new Log4j 2 file format. If you customized logging
settings in prior versions, you must manually apply those changes to the new
configuration file.
Previous behavior:
In Cloudera Manager 7.13.2 and
earlier releases, Cloudera Manager used Reload4J (a fork of Log4J version 1) for
system logging and internal communications. This framework triggered false-positive
vulnerability reports in automated security scanning tools. Cloudera Manager read
logging properties from the
/etc/cloudera-scm-server/log4j.properties file.
New behavior:
Cloudera Manager no longer packages
or uses Reload4J. Cloudera Manager now uses Apache Log4j 2 for internal
communications and system logging:
Cloudera Manager now reads logging configurations from the
/etc/cloudera-scm-server/log4j2.properties file.
Cloudera Manager ignores the previous
/etc/cloudera-scm-server/log4j.properties file.
Summary: Cloudera Manager validates the
location argument in addCustomCerts requests against the configured
CMCA storage mode
Cloudera Manager now validates the location parameter in
addCustomCerts API requests against the inferred Cloudera Manager
Certificate Authority (CMCA) storage mode (derived from the
HOST_CERT_GENERATOR setting) before issuing the command. Invalid
requests fail immediately with an HTTP 400 error
(IllegalArgumentException), and Cloudera Manager does not create
or persist a database command. You can bypass this validation by setting the new
optional parameter disableLocationValidation to
true.
Previous behavior:
Previously, Cloudera Manager
did not validate the location parameter against
HOST_CERT_GENERATOR or inferred CMCA storage mode before issuing
addCustomCerts. The API accepted the request, persisted the
command, and showed it under Recent Commands.
At
command execution, Cloudera Manager resolved location as follows:
Non-empty location: Used the supplied path directly. Cloudera
Manager did not compare it to the configured CMCA directory or to
database-backed storage.
Omitted or blank location:
If there was no ROOT CA certificate in the Auto-TLS certificate database,
Cloudera Manager used the legacy default filesystem path
/var/lib/cloudera-scm-server/certmanager.
If a ROOT CA certificate existed in that database, Cloudera Manager
extracted the CMCA archive from the database into a temporary directory, ran
certmanager there, and (on success) persisted updated host certificates back
to the database. This path did not use HOST_CERT_GENERATOR
to locate an on-disk CMCA tree.
If callers supplied an incorrect location, the command failed
asynchronously during execution with generic errors or stack traces instead of
rejecting the request at submission time.
New behavior:
By default
(disableLocationValidation: false), Cloudera Manager validates
the location argument against the inferred CMCA storage mode before
assembling command steps:
Filesystem-backed CMCA: When
HOST_CERT_GENERATOR ends with
/generate_host_cert, you must pass a
location argument that matches the parent CMCA directory
(for example, if HOST_CERT_GENERATOR is
/opt/cloudera/CMCA/generate_host_cert, pass
"location": "/opt/cloudera/CMCA"). Cloudera Manager
compares normalized paths. Requests fail with an HTTP 400 error if you omit
location or if location does not match the
configured CMCA directory.
Database-backed CMCA: When
HOST_CERT_GENERATOR equals the temporary directory marker,
you must omit the location parameter entirely. If you provide
a location parameter, Cloudera Manager rejects the request
with an HTTP 400 error.
Legacy or Non-standard Setups: When
HOST_CERT_GENERATOR uses a pattern from which Cloudera
Manager cannot infer the CMCA location, Cloudera Manager skips validation and
retains the previous flexibility for passing or omitting
location.
When validation fails, Cloudera Manager rejects
the request before persisting the command, which prevents generating a command ID or
displaying an entry under Recent Commands.
Summary: Cloudera Manager 7.13.3
removes legacy API endpoints for end-of-support CDH 3.x, 4.x, and 5.x releases. API
requests to these endpoints now return HTTP 404 Not Found instead
of HTTP 400 Bad Request or HTTP 410
Gone.
Previous behavior:
Cloudera Manager returned the
following HTTP status codes when calling deprecated CDH 5 API endpoints:
POST /{serviceName}/commands/hbaseUpgrade → HTTP 400
Bad Request
POST /{serviceName}/commands/impalaEnableLlamaRm →
HTTP 410 Gone
POST /{serviceName}/commands/impalaDisableLlamaRm →
HTTP 410 Gone
POST /{serviceName}/commands/impalaEnableLlamaHa →
HTTP 410 Gone
POST /{serviceName}/commands/impalaDisableLlamaHa →
HTTP 410 Gone
New behavior:
Cloudera Manager returns an
HTTP 404 Not Found status code for all requests to these
unsupported API endpoints:
POST /{serviceName}/commands/hbaseUpgrade → HTTP 404
Not Found
POST /{serviceName}/commands/impalaEnableLlamaRm →
HTTP 404 Not Found
POST /{serviceName}/commands/impalaDisableLlamaRm →
HTTP 404 Not Found
POST /{serviceName}/commands/impalaEnableLlamaHa →
HTTP 404 Not Found
POST /{serviceName}/commands/impalaDisableLlamaHa →
HTTP 404 Not Found
