Known Issues and Workarounds in Cloudera Director

The following sections describe the current known issues in Cloudera Director.

Usernames should support user@domain.com format

When "." is used in a username, the Cloudera Director UI fails to create the user; Cloudera Director client does create a user, but the get user and update user commands return 404.

Tag on creation not available for AWS China and GovCloud

The AWS plugin in Cloudera Director 2.5 now supports tagging instances on creation for reliability purposes. However, neither the AWS China region nor AWS GovCloud currently support this functionality. For more information about tagging on creation for AWS instances, see the AWS blog article Tag EC2 Instances & EBS Volumes on Creation.

Workaround: Use Cloudera Director 2.4 if you require tag-on-create functionality for these regions until the regions have been updated by AWS.

Cloudera Director may orphan AWS Spot instances

Cloudera Director tags AWS instances with an instance id. Due to eventual consistency in the AWS API, Cloudera Director may not find the tagged instances during the bootstrap or update process.

Added instance groups are not configured based on their instance type

Newly added instance groups are not automatically configured. Roles on the new instances will be given the same configuration as existing roles even if the new instance uses a different instance type than the old instances.

Workaround: Update the role group in Cloudera Manager after the cluster update completes.

Maximum length of environment name is misleading

Parsing of a Cloudera Director configuration file can produce errors indicating that the environment name and, sometimes additionally, the deployment name are too long, even though the names were not specified in the file. This is a consequence of Cloudera Director automatically generating those names, based on the cluster name, when they are not explicitly given in the file. When the cluster name is long, the automatically-generated names exceed the length limits.

Workaround: Provide explicit names for the environment and deployment in the configuration file. Examples:
environmentName: MyEnvironment
deploymentName: MyDeployment

Timeouts sending usage bundles

When usage-based billing is enabled, Cloudera Director may eventually cease sending usage bundles. An error similar to this is shown in the Director log:
WARN [InternalReportingService RUNNING] - 
c.c.m.r.u.g.t.TapeUsageBundleReportingService: Failed to 
dispatch bundle UsageBundleMetadata{version='v1', 
licenseKey='REDACTED', ...}. 
com.cloudera.metering.reporting.usage.generation.dispatch.
UsageBundleDispatchException: New upload request failed 
... 
Caused by: java.util.concurrent.TimeoutException: Timeout waiting for task. 

Workaround: Restart Cloudera Director. Any usage bundles that are queued for submission before restart will be sent, and normal usage collection should resume.

AWS rate limiting due to large number of EBS volumes

Standing up a cluster with a large number of EBS volumes might trigger rate limiting on EBS allocation requests. The effect can spread to other calls from Cloudera Director to AWS.

Workaround: No more than 10 EBS volumes should be attached at a time.

Cloudera Director cannot deploy Cloudera Navigator Key Trustee Server

Cloudera Navigator Key Trustee Server cannot be one of the services deployed by Cloudera Director.

Workaround: Set up Cloudera Navigator Key Trustee Server via Cloudera Manager if using Cloudera Director 2.4 and above.

Resize script cannot resize XFS partitions

Cloudera Director is unable to resize XFS partitions, which makes creating an instance that uses the XFS filesystem fail during bootstrap.

Workaround: Use an image with an ext filesystem such as ext2, ext3, or ext4.

Cloudera Director does not set up external databases for Sqoop2

Cloudera Director cannot set up external databases for Sqoop2.

Workaround: Set up databases for this service as described in Cloudera Manager and Managed Service Databases.

Metrics not displayed for clusters deployed in Cloudera Manager 5.4 and earlier clusters

Clusters deployed in Cloudera Manager version 5.4 and lower might not have metrics displayed in the web UI if these clusters share the same name as previously deleted clusters.

Workaround: Use Cloudera Manager 5.5 and higher.

Changes to Cloudera Manager username and password must also be made in Cloudera Director

If the Cloudera Manager username and password are changed directly in Cloudera Manager, Cloudera Director can no longer add new instances or authenticate with Cloudera Manager. Username and password changes must be implemented in Cloudera Director as well. For more information on keeping Cloudera Director and Cloudera Manager in sync, see CDH Cluster Management Tasks.

Workaround: Use the Cloudera Director web UI to update the Cloudera Manager username and password.

Cloudera Director may use AWS credentials from instance of Cloudera Director server

Cloudera Director Server uses the AWS credentials from a configured Environment, as defined in a client configuration file or through the Cloudera Director web UI. If the Environment is not configured with credentials in Cloudera Director, the Cloudera Director server instead uses the AWS credentials that are configured on the instance on which the Cloudera Director server is running. When those credentials differ from the intended ones, EC2 instances may be allocated under unexpected accounts. Ensure that the Cloudera Director server instance is not configured with AWS credentials.

Severity: Medium

Workaround: Ensure that the Cloudera Director Environment has correct values for the keys. Alternatively, use IAM profiles for the Cloudera Director server instance.

Root partition resize fails on CentOS 6.5 (HVM)

Cloudera Director cannot resize the root partition on Centos 6.5 HVM AMIs. This is caused by a bug in the AMIs. For more information, see the CentOS Bug Tracker.

When using RDS and MySQL, Hive Metastore canary may fail in Cloudera Manager

If you include Hive in your clusters and configure the Hive metastore to be installed on MySQL, Cloudera Manager may report, "The Hive Metastore canary failed to create a database." This is caused by a MySQL bug in MySQL 5.6.5 or higher that is exposed when used with the MySQL JDBC driver (used by Cloudera Director) version 5.1.19 or lower. For information on the MySQL bug, see the MySQL bug description.

Workaround: Depending on the driver version installed by Cloudera Director from your platform's software repositories, select an older MySQL version that does not have this bug.