This is the documentation for Cloudera Manager 5.0.0.
Documentation for other versions is available at Cloudera Documentation.

Fixed Issues

Fixed Issues in Cloudera Manager 5.0.0

Cannot Restore a Snapshot of a deleted HBase Table

If you take a snapshot of an HBase table, and then delete that table in HBase, you will not be able to restore the snapshot.

Severity: Med

Workaround: Use the "Restore As" command to recreate the table in HBase.

Stop dependent HBase services before enabling HDFS Automatic Failover.

When enabling HDFS Automatic Failover, you need to first stop any dependent HBase services. The Automatic Failover configuration workflow restarts both NameNodes, which could cause HBase to become unavailable.

Severity: Medium

New schema extensions have been introduced for Oozie in CDH 4.1

In CDH 4.1, Oozie introduced new versions for Hive, Sqoop and workflow schema. To use them, you must add the new schema extensions to the Oozie SchemaService Workflow Extension Schemas configuration property in Cloudera Manager.

Severity: Low

Workaround: In Cloudera Manager, do the following:

  1. Go to the CDH 4 Oozie service page.
  2. Go to the Configuration tab, View and Edit.
  3. Search for "Oozie Schema". This should show the Oozie SchemaService Workflow Extension Schemas property.
  4. Add the following to the Oozie SchemaService Workflow Extension Schemas property:
  5. Save these changes.

YARN Resource Scheduler user FairScheduler rather than FIFO.

Cloudera Manager 5.0.0 sets the default YARN Resource Scheduler to FairScheduler. If a cluster was previously running YARN with the FIFO scheduler, it will be changed to FairScheduler next time YARN restarts. The FairScheduler is only supported with CDH4.2.1 and later, and older clusters may hit failures and need to manually change the scheduler to FIFO or CapacityScheduler.

Severity: Medium

Workaround: For clusters running CDH 4 prior to CDH 4.2.1:
  1. Go the YARN service Configuration page
  2. Search for "scheduler.class"
  3. Click in the Value field and select the schedule you want to use.
  4. Save your changes and restart YARN to update your configurations.

Resource Pools Summary is incorrect if time range is too large.

The Resource Pools Summary does not show correct information if the Time Range selector is set to show 6 hours or more.

Severity: Medium

Workaround: None.

When running the MR1 to MR2 import on a secure cluster, YARN jobs will fail to find container-executor.cfg

Workaround: Restart YARN after the import steps finish. This causes the file to be created under the YARN configuration path, and the jobs now work.

When upgrading to Cloudera Manager 5.0.0, the "Dynamic Resource Pools" page is not accessible

When upgrading to Cloudera Manager 5.0.0, users will not be able to directly access the "Dynamic Resource Pools" page. Instead, they will be presented with a dialog saying that the Fair Scheduler XML Advanced Configuration Snippet is set.

  1. Go to the YARN service.
  2. Select Configuration > View and Edit.
  3. Copy the value of the Fair Scheduler XML Advanced Configuration Snippet into a file.
  4. Clear the value of Fair Scheduler XML Advanced Configuration Snippet.
  5. Recreate the desired Fair Scheduler allocations in the Dynamic Resource Pools page, using the saved file for reference.

New Cloudera Enterprise licensing is not reflected in the wizard and license page

Workaround: None.

The AWS Cloud wizard fails to install Spark due to missing roles

Workaround: Do one of the following:
  • Use the traditional install wizard
  • Open a new window, click the Spark service, click on the Instances tab, click Add, add all required roles to Spark. Once the roles are successfully added, click the Retry button on the First Run page in the wizard.

Spark on YARN requires manual configuration

Spark on YARN requires the following manual configuration to work correctly: modify the YARN Application Classpath by adding /etc/hadoop/conf, making it the very first entry.

Workaround: Add /etc/hadoop/conf as the first entry in the YARN Application classpath.

Monitoring works with Solr and Sentry only after configuration updates

Cloudera Manager monitoring does not work out of the box with Solr and Sentry on Cloudera Manager 5. The Solr service is in Bad health, and all Solr Servers have a failing "Solr Server API Liveness" health check.

Severity: Medium

Workaround: Complete the configuration steps below:

  1. Create "HTTP" user and group on all machines in the cluster (with useradd 'HTTP' on RHEL-type systems).
  2. The instructions that follow this step assume there is no existing Solr Sentry policy file in use. In that case, first create the policy file on /tmp and then copy it over to the appropriate location in HDFS that Solr Servers check. If there is already a Solr Sentry policy in use, it must be modified to add the following [group] / [role] entries for 'HTTP'. Create a file (for example, /tmp/cm-authz-solr-sentry-policy.ini) with the following contents:
    HTTP = collection = admin->action=query
  3. Copy this file to the location for the "Sentry Global Policy File" for Solr. The associated config name for this location is sentry.solr.provider.resource, and you can see the current value by navigating to the Sentry sub-category in the Service Wide configuration editing workflow in the Cloudera Manager UI. The default value for this entry is /user/solr/sentry/sentry-provider.ini. This refers to a path in HDFS.
  4. Check if you have entries in HDFS for the parent(s) directory:
    sudo -u hdfs hadoop fs -ls /user
  5. You may need to create the appropriate parent directories if they are not present. For example:
    sudo -u hdfs hadoop fs -mkdir /user/solr/sentry
  6. After ensuring the parent directory is present, copy the file created in step 2 to this location, as follows:
    sudo -u hdfs hadoop fs -put /tmp/cm-authz-solr-sentry-policy.ini /user/solr/sentry/sentry-provider.ini
  7. Ensure that this file is owned/readable by the solr user (this is what the Solr Server runs as):
    sudo -u hdfs hadoop fs -chown solr /user/solr/sentry/sentry-provider.ini
  8. Restart the Solr service. If both Kerberos and Sentry are being enabled for Solr, the MGMT services also need to be restarted. The Solr Server liveness health checks should clear up once SMON has had a chance to contact the servers and retrieve metrics.

Out-of-memory errors may occur when using the Reports Manager

Out-of-memory errors may occur when using the Cloudera Manager Reports Manager.

Workaround: Set the value of the "Java Heap Size of Reports Manager" property to at least the size of the HDFS filesystem image (fsimage) and restart the Reports Manager.

Applying license key using Internet Explorer 9 and Safari fails

Cloudera Manager is designed to work with IE 9 and above and Safari. However the file upload widget used to upload a license currently doesn't work with IE 9 or Safari. Therefore, installing an enterprise license doesn't work.

Workaround: Use another supported browser.

Fixed Issues in Cloudera Manager 5.0.0 Beta 2

The HDFS Canary Test is disabled for secured CDH 5 services.

Due to a bug in Hadoop's handling of multiple RPC clients with distinct configurations within a single process with Kerberos security enabled, Cloudera Manager will disable the HDFS canary test when security is enabled so as to prevent interference with Cloudera Manager's MapReduce monitoring functionality.

Severity: Medium

Workaround: None

Not all monitoring configurations are migrated from MR1 to MR2.

When MapReduce v1 configurations are imported for use by YARN (MR2), not all of the monitoring configuration values are currently migrated. Users may need to reconfigure custom values for properties such as thresholds.

Severity: Medium

Workaround: Manually reconfigure any missing property values.

"Access Denied" may appear for some features after adding a license or starting a trial.

After starting a 60-day trial or installing a license for Enterprise Edition, you may see an "access denied" message when attempting to access certain Enterprise Edition-only features such as the Reports Manager. You need to log out of the Admin Console and log back in to access these features.

Severity: Low

Workaround: Log out of the Admin Console and log in again.

Hue must set impersonation on when using Impala with impersonation.

When using Impala with impersonation, the impersonation_enabled flag must be present and configured in the hue.ini file. If impersonation is enabled in Impala (i.e. Impala is using Sentry) then this flag must be set true. If Impala is not using impersonation, it should be set false (the default).

Workaround: Set advanced configuration snippet value for hue.ini as follows:
  1. Go to the Hue Service Configuration Advanced Configuration Snippet for hue_safety_valve.ini under the Hue service Configuration settings, Service-Wide > Advanced category.
  2. Add the following, then uncomment the setting and set the value True or False as appropriate:
    # Settings to configure Impala
      # Turn on/off impersonation mechanism when talking to Impala
      ## impersonation_enabled=False

Cloudera Manager Server may fail to start when upgrading using a PostgreSQL database.

If you're upgrading to Cloudera Manager 5.0.0 beta 1 and you're using a PostgreSQL database, the Cloudera Manager Server may fail to start with a message similar to the following:
ERROR [main:dbutil.JavaRunner@57] Exception while executing 
java.lang.RuntimeException: java.sql.SQLException: Batch entry <xxx> insert into REVISIONS 
was aborted. Call getNextException to see the cause.
Workaround: Use psql to connect directly to the server's database and issue the following SQL command:
alter table REVISIONS alter column MESSAGE type varchar(1048576);
After that, your Cloudera Manager server should start up normally.

Fixed Issues in Cloudera Manager 5.0.0 Beta 1

After an upgrade from Cloudera Manager 4.6.3 to 4.7, Impala does not start.

After an upgrade from Cloudera Manager 4.6.3 to 4.7 when Navigator is used, Impala will fail to start because the Audit Log Directory property has not been set by the upgrade procedure.

Severity: Low.

Workaround: Manually set the property to /var/log/impalad/audit. See the Service Auditing Properties section of the Cloudera Navigator Installation and User Guide for more information.