Cloudera Docs

Behavioral Changes

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.2.

Cloudera Manager 7.13.2 introduces functional adjustments, behavioral updates, and includes all cumulative hotfixes from 7.13.1.100 through 7.13.1.700. For a comprehensive record of all functional adjustments in Cloudera Manager 7.13.1.x, see Behavioral Changes 7.13.1.x.

Cloudera Manager 7.13.2

Summary: Enhanced the security of Spark by implementing new default configuration settings
Previous behavior:
  1. spark.ui.enabled=true: possible initiation of an HTTP service that can be accessed from external hosts.
  2. spark.io.encryption.keySizeBits=128: the default Spark keySizeBits
New behavior:
  1. spark.ui.enabled=false: preventing initiation of an HTTP service that can be accessed from external hosts.
  2. spark.io.encryption.keySizeBits=256: the default Spark keySizeBits has been increased from 128 to 256
Summary: Cloudera Manager 7.13.2 introduces changes to its underlying SAML library, impacting Service Provider (SP) metadata signing, response binding options, and message signing algorithms.
Previous behavior:
  • Metadata Signing: The SAML library supported the signing of the Service Provider’s (Cloudera Manager) metadata.
  • Response Binding: SAML Response Binding supported only POST & ARTIFACT, with the default set to POST.
  • Message Signing Algorithm: You could select the Message Signing Algorithm from a list: RSA_SHA1, RSA_SHA256, RSA_SHA384, RSA_SHA512.
New behavior:
  • Metadata Signing: The SAML library no longer supports the signing of the Service Provider’s (Cloudera Manager) metadata.
  • Response Binding: SAML Response Binding will now support only POST & REDIRECT, with the default set to POST.
  • Message Signing Algorithm: The Message Signing Algorithm defaults to RSA_SHA256 (which is secure), and Cloudera Manager will provide no options to select from the UI.
Summary: When Cloudera Manager runs in FIPS-enabled mode, it does not use the JVM’s default cacerts truststore, as it is in a non-FIPS JKS format.
Previous behavior:

In standard (non-FIPS) mode, Cloudera Manager relies on the JVM’s default cacerts truststore, which is in JKS format. This allows Cloudera Manager to automatically trust the default CA certificates shipped with the JDK and establish secure connections to external endpoints such as S3 or Cloudera repositories.

New behavior:

In FIPS mode, only FIPS-compliant keystore formats (such as BCFKS) are permitted. Because the default cacerts is in JKS format, Cloudera Manager skips loading it to prevent startup failures and instead uses the Cloudera Manager-provided truststore exclusively. This ensures consistent and reliable operation under FIPS compliance, but means that Cloudera Manager does not automatically trust certificates present only in the JVM's default cacerts.

As a result, connections to certain external endpoints (for example, public cloud services, S3, Cloudera download URLs) might fail unless their certificates are also present in the Cloudera Manager-provided truststore.

To preserve the default JVM truststore behavior in FIPS mode, convert the JKS-formatted cacerts to BCFKS using keytool. For more information, see Preserving the default JVM truststore behavior in FIPS mode.
Summary: Removed the hbase.secure.rpc.engine configuration property
Previous behavior:
The hbase.secure.rpc.engine configuration property is obsolete because HBase performs replication securely by default.
New behavior:
The hbase.secure.rpc.engine configuration property is removed from the Cloudera Manager because it is obsolete and no longer needed.
The default value of the Region Mover Threads configuration is updated
Previous behavior:
The current default value for the configuration > HBase > Configuration > Region Mover Threads is set to 1
New behavior:
As only a single thread is utilized for region movement, the overall operation exhibits poor performance. The default value is updated 20, which is proposed to leverage 20 region mover threads and is expected to yield substantial performance improvements.
For more information see Rolling Restart.
HBase BucketCache configuration names and descriptions are incorrect in Cloudera Manager
Previous behavior:
The display names and descriptions of the BucketCache configuration names are as follows:
  • hbase.rs.evictblocksonclose = HBase region server cache data blocks on read (Cache data blocks on read)
  • hbase.block.data.cacheonread = HBase region server evict blocks of a file cache when the file is closed (Evict all blocks of a given file from the block cache when the file is closed)
New behavior:
The display names and descriptions are corrected in Cloudera Manager for the following configuration items:
  • hbase.rs.evictblocksonclose = HBase RegionServer evict blocks on closed (Evict all blocks of a given file from the block cache when the region is closed)
  • hbase.block.data.cacheonread = HBase RegionServer cache data blocks on read (Cache data blocks on read)
HBOSS related configuration items are removed from Cloudera Manager
Previous behavior:
Cloudera Manager contains the following HBOSS related configuration items.
  • fs.hboss.fs.s3a.impl
  • fs.hboss.sync.impl
  • fs.s3a.connection.maximum
  • fs.s3a.threads.max
New behavior:
The above items are removed from HBase Cloudera Manager configuration because HBOSS support is deprecated.
The BucketCache related configuration items are dynamically configurable in Cloudera Manager
Previous behavior:
The following HBase BucketCache related configuration items were previously not dynamically configurable in Cloudera Manager, and users had to configure them using the advanced configuration snippet (safety valve).
  • hbase.bucketcache.acceptfactor
  • hbase.bucketcache.minfactor
New behavior:
You can now configure these items dynamically in Cloudera Manager. The change takes effect immediately without requiring an HBase service restart.
HBase supports Log4J2 for logging
Previous behavior:
HBase used Log4j 1.x for its logging framework.
New behavior:
HBase now uses Log4j2 due to its enhanced performance, improved features, and ongoing security support.
Summary: Allowing configurable File Descriptor (FD) limits in supervisord
Previous behavior:

Each service role ran with the File Descriptor (FD) limit you explicitly configured in Cloudera Manager, or with the default limit if you set none.

New behavior:

The new behavior allows administrators to increase the FD limit globally across all managed services by modifying the relevant supervisord service file or system.conf, regardless of individual role settings.

Configuration Rules: The FD limit you define in /usr/lib/systemd/system/cloudera-scm-supervisord.service or /etc/systemd/system.conf (depending on the Cloudera Manager version) applies to the supervisord daemon itself. supervisord inherits this limit for service roles only when you configure no explicit FD limit for that role.
Summary: Apache Ranger policies for Kafka topics and the consumer group used by Atlas asynchronous import
Previous behavior:

Cloudera Manager did not add default Apache Ranger policies that grant the atlas user permission to create, edit, or delete Kafka topics with the ATLAS_IMPORT_ prefix or to access the atlas_import consumer group.

New behavior:

Cloudera Manager adds default Apache Ranger policies so the atlas user can create, configure, alter, publish, and delete Kafka topics with the ATLAS_IMPORT_ prefix and can use the atlas_import consumer group for Atlas asynchronous import.

Summary: Removed EventCounter from Hadoop
Previous behavior:
The EventCounter functionality was deprecated and later removed by Apache Hadoop.
New behavior:
The occurrences of EventCounter have been removed from the Java code and log4j configuration files.
Summary: Component-level custom Java home configuration removed for Kafka, Schema Registry, SMM, and SRM
Previous behavior:

You could configure a component-specific Java home for Kafka, Schema Registry, Streams Messaging Manager (SMM), and Streams Replication Manager (SRM).

New behavior:

The component-level custom Java home configuration options are removed for Kafka, Schema Registry, SMM, and SRM. These services now use the host-level java_home configuration. If you previously set a component-specific Java home for any of these services, verify the host-level java_home setting after upgrading.

In a Cloudera Manager 7.13.2.0 Cluster Effective FD Limit
You configure HDFS roles with an FD limit of 72K. They run with 72K.
You configure Ozone roles with an FD limit of 48K. They run with 48K.
The supervisord service file sets an FD limit of 64K. supervisord itself uses 64K.
You do not configure Hive roles explicitly. Hive inherits the 64K limit from supervisord.

If you want to increase the File Descriptor (FD) limit across all services managed by Cloudera Manager, you should perform the following steps:

Option A: If Cloudera Manager version is 7.13.2 or higher
  1. Go to /usr/lib/systemd/system/cloudera-scm-supervisord.service.
  2. Make the change that is prescribed in the cloudera-scm-supervisord.service file to increase the FD limit across services.
  3. Then run systemctl daemon-reload followed by systemctl restart cloudera-scm-supervisord.
Option B: If Cloudera Manager version is lower than 7.13.2
  1. Go to /etc/systemd/system.conf.
  2. This file will contain #DefaultLimitNOFILE=. You need to uncomment this line (if it is commented) and set an FD value of your choice.
  3. Then run systemctl daemon-reload followed by systemctl restart cloudera-scm-supervisord.

After you implement this change, the FD limit will apply across all services managed by Cloudera Manager.