About jadair

jadair · ‎06-08-2016

Neither of those features are currently supported or on the roadmap.

jadair · ‎03-24-2016

When you say you're having the same issue, I need some clarification. The original poster was complaining that Director could not make an HTTP connection to Cloudera Manager on port 7180. You seem to be saying that Director (and you yourself) cannot establish an SSH connection to an instance (on port 22). These are likely two different problems. If this is correct, can you please open a separate question, and post a snippet from Director's application.log showing the failure to establish a connection? That way future forum users can benefit from whatever solution we find.

jadair · ‎03-10-2016

I recommend keeping an eye on that issue in the plugin repository. If a fix appears there, you should be able to try out a local build of the plugin in your Cloudera Director installation before we ship an updated version of the plugin in a future Cloudera Director release. I will try to comment here if I hear anything about fix versions.

jadair · ‎03-10-2016

Per the Google Cloud Platform documentation on Using Subnetworks, there are two kinds of networking in Google Cloud Platform, the original Legacy (non-subnet) Networks, and the newer Subnet Networks. From the description in your post, I assume you are using Subnet Networks. The Google plugin for Cloudera Director currently supports only Legacy (non-subnet) Networks. I have filed an enhancement request issue (#118) against the plugin, and made sure developers at Cloudera and Google are aware of the issue.

jadair · ‎01-29-2016

I'm glad my suggestion for how to diagnose was helpful. Thanks for commenting on what turned out to be the specific problem, in case your solution is helpful to another user in the future.

jadair · ‎01-28-2016

If you ssh into the instance and try to execute those commands manually, it should be apparent what is going wrong. Could be network configuration issues trying to talk to the yum repo, etc.

jadair · ‎01-22-2016

What versions of Cloudera Director and Cloudera Manager are you using? You may want to take a look at this comment for possible info on problems with version incompatibilities: http://community.cloudera.com/t5/Cloudera-Director-Cloud-based/Cloudera-Director-bootstrap-failing-on-Installing-cloudera/m-p/35949#M480

jadair · ‎11-30-2015

Start/stop of instances is not supported via Director. You are probably seeing corrupted blocks because ephemeral storage is lost during the stop/start cycle, but per the HDFS Durability section of the reference architecture, HDFS on EBS is not a supported configuration: <http://www.cloudera.com/content/www/en-us/documentation/other/reference-architecture/PDF/cloudera_ref_arch_aws.pdf>. A different way to achieve your goal of only paying for instances when you need them using Director would be to define your cluster in a configuration file, create the cluster using Director when you need it, and tear it down afterward.

jadair · ‎10-14-2015

For your reference, here are the contents of reference.conf inside the jar: # # Copyright (c) 2013 Cloudera, Inc. All rights reserved. # deploymentName: ${?name}" Deployment" environmentName: ${?name}" Environment" # # Generic defaults that apply to all configuration files # cloudera-manager { username: admin password: admin } cluster { products { CDH: 5 # latest from 5.x branch } } roles { HDFS_MASTERS: [NAMENODE, SECONDARYNAMENODE] HDFS_WORKERS: [DATANODE] MAPREDUCE_MASTERS: [JOBTRACKER] MAPREDUCE_WORKERS: [TASKTRACKER] YARN_MASTERS: [RESOURCEMANAGER, JOBHISTORY] YARN_WORKERS: [NODEMANAGER] ZOOKEEPER_MASTERS: [SERVER] ZOOKEEPER_WORKERS: [] HBASE_MASTERS: [MASTER] HBASE_WORKERS:[REGIONSERVER] HIVE_MASTERS: [HIVESERVER2, HIVEMETASTORE] HIVE_WORKERS: [] OOZIE_MASTERS: [OOZIE_SERVER] OOZIE_WORKERS: [] HUE_MASTERS: [HUE_SERVER] HUE_WORKERS: [] IMPALA_MASTERS: [CATALOGSERVER, STATESTORE] IMPALA_WORKERS: [IMPALAD] SQOOP_MASTERS: [SQOOP_SERVER] SQOOP_WORKERS: [] FLUME_MASTERS: [] FLUME_WORKERS: [AGENT] SOLR_MASTERS: [SOLR_SERVER] SOLR_WORKERS: [] SPARK_ON_YARN_MASTERS: [SPARK_YARN_HISTORY_SERVER] SPARK_ON_YARN_WORKERS: [] SENTRY_MASTERS: [SENTRY_SERVER] SENTRY_WORKERS: [] }

jadair · ‎10-12-2015

As you say, ${instance.cc28} is a reference within the same config file. The other reference, ${roles.HDFS_Workers}, uses HOCON fallback chaining, and is actually referring to a variable defined in reference.conf inside the jar. The fallback order is the file you provide (in this case aws.reference.conf), then a provider-specific set of defaults that we ship (in this case aws.conf), then a set of global defaults that we ship (reference.conf). Although it is meant to simplify your configuration, you are not the first to be confused by the behavior. We plan to remove it in a future release.

Online	Offline
Last Visited	‎08-19-2019 12:16 PM

Member Since	‎10-28-2014 12:50 PM
Last Visited	‎08-19-2019 12:16 PM
Posts	71
Kudos received	11

Cloudera Community

Re: Director Not Increasing Heap of Host Monitor

Re: How to increase database pool for Director?

Re: How to increase database pool for Director?

Re: Azure: Changing instance type post deployment

Re: Cloudera Altus support of CDH on CentOS 7.6

Re: encryption on rds and ebs

Re: Cloudera Director 2.0 infinite loop Bootstrapp...

Re: Cloudera Director 2.0 - Specify GCP subnet in ...

Re: Cloudera Director 2.0 - Specify GCP subnet in ...

Re: Cloudera Manager bootstrap failing on 'Install...

Re: Cloudera Manager bootstrap failing on 'Install...

Re: Issue with AMI with Parcel Preloaded

Re: Corrupted HDFS on Restart of Cluster Built wit...

Re: Director Config File Role Assignment

Re: Director Config File Role Assignment