Member since
02-18-2014
94
Posts
23
Kudos Received
23
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
3390 | 08-29-2019 07:56 AM | |
4130 | 07-09-2019 08:22 AM | |
2109 | 07-01-2019 02:21 PM | |
3608 | 03-19-2019 07:42 AM | |
2783 | 09-04-2018 05:29 AM |
09-04-2018
05:29 AM
Hi dturner, The bootstrap-remote command will remain in Cloudera Director for the foreseeable future. What we're planning to remove is the bootstrap command, without the "-remote" bit at the end. The bootstrap-remote command communicates with a Director server, while the bootstrap command does all of the work locally within the client. We call using the non-remote bootstrap command using the client in "standalone" mode, and it's those non-remote commands that are going away. We realized that having such similar client commands was pretty confusing. For example, some folks would use the bootstrap command (non-remote) to spin up a cluster, but then be surprised that their Director server elsewhere wouldn't know about it. Overall, it's just better to use the server and remote client commands anyway. For one thing, the server API and Java / Python SDKs are available for servers, but don't work for clusters created from the "standalone" client bootstrap command. I hope that helps clear up the confusion.
... View more
08-13-2018
10:30 AM
1 Kudo
Hi iasindev, For case #1, when using bootstrap-remote, most of the work is done on the associated Director server, so check the logs there for problems. It could be the same problem that surfaced in #2. In #2, the error is occurring when Director is failing to access the CDH parcel repository over https. Are you hosting your own repository, or have you customized the Director truststore to no longer include common trusted certificates? Older Director releases are available under https://archive.cloudera.com/director/ . Just drill down for your operating system to find the version you need.
... View more
08-06-2018
06:16 AM
Hi Tomas79, Thanks for bringing up this issue! I've filed an internal trouble ticket for this failure to handle Unicode, so that we can address it in a future release.
... View more
07-02-2018
06:02 AM
Hi Tomas79, I think a Python script will work if you start it with a shebang (e.g., #/usr/bin/env python). Director uses essentially the following shell command to run a script, so I can see a Python script working with it. sudo chmod 700 'scriptName' && sudo 'scriptName' Even so, running a Python script directly is a little hacky because we haven't thought about Director running anything other than shell scripts with this capability, so I can't guarantee that this command won't change in the future to not work with a Python script. However, something like the following shell script will be fine. #!/usr/bin/env bash
python <<EOF
print 'Hello world!'
EOF Or: #!/usr/bin/env bash
curl -O http://host/path/to/downloadable/script.py
python script.py Or rather than downloading the script, bake it into your AMI / image. So, there are a few options.
... View more
06-05-2018
08:04 AM
Great! Thanks for the follow-up.
... View more
06-04-2018
11:41 AM
1 Kudo
Hi sg321, Your configuration appears correct, including the substitution of the environment variable for the private key path. It's true that Director will not accept SSH credentials that have neither a password nor a private key defined. My first guess is that, despite your check that the "path_to_private_key" environment variable is set, it still isn't visible to the Director process. If it isn't visible, then the substitution using ${?path_to_private_key} doesn't happen, and the entire "privateKey" property is left out; that fits the symptoms here. Try changing the substitution to only ${path_to_private_key}, without the question mark; this way, if the substitution cannot be made, parsing will fail with an error. Reference for HOCON substitution rules: https://github.com/lightbend/config/blob/master/HOCON.md#substitutions My second guess is that the ssh section you posted may be nested at the wrong location in the HOCON configuration file, and the parser is actually looking elsewhere. Is it possible for you to post your entire spot-director.conf file? If so, please do remove any passwords or other sensitive information from it.
... View more
05-29-2018
08:41 AM
Hello icepear, Make sure that the Cloudera Director server is still running by using `ps` on its machine. Also check its application.log file to make sure there were no problems with it starting up. You should not have to set JAVA_HOME for Cloudera Director, because the startup scripts that ship with it hunt for a JDK or JRE to use. (This is not a cloud-specific thing.) Assuming that Director is running, try to access it locally from the machine it is running on, e.g., `curl http://localhost:7189`. If that works, then the server is running normally; otherwise, check the logs. Once Director is running normally, see if you can reach it from your browser. If you are running on a machine that is not inside the same GCP network where Director is running, and you do not have a VPN connection established to GCP, then you must access Director through the public IP address associated with Director's machine. In that case, firewall rules must allow inbound TCP traffic over port 7189 from your IP address / range.
... View more
02-22-2018
06:25 AM
1 Kudo
Hi Behel, Yes, we didn't get the example application.properties values correct in the 2.7.0 release, but the cmJavaPackages and defaultCmJavaPackages are the correct ones to set. cmJavaPackages is a list, so the syntax is a little odd (and our docs might not be quite right, still): lp.bootstrap.packages.cmJavaPackages[0]: ".*=oracle-j2sdk1.8" lp.bootstrap.packages.defaultCmJavaPackage: oracle-j2sdk1.8 The "javaPackage" property doesn't have any effect, so you can remove it. When you use the UI, Cloudera Director uses the AUTO Java installation strategy, so the settings won't have any effect on the cluster instances, just on the CM instance. Under AUTO, Director lets Cloudera Manager handle the cluster instances, and they only get Java 7 and maybe Java 6, depending on the version. To get just Java 8 on everything, use the DIRECTOR_MANAGED Java installation strategy, which requires you to use a client configuration file. Your setup of the Cloudera Director repo to make the oracle-j2sdk1.8 package available looks correct to me. You can always test it out manually by running yum from the command line. Do let me know if the above helps you get things working! Bill
... View more
11-02-2017
07:51 AM
1 Kudo
Hi l0pht, Cloudera Director does not support setting up an HA installation of Cloudera Manager out of the box. Only one Cloudera Manager instance is bootstrapped at a time by Cloudera Director. Here are the documented steps for configuring Cloudera Manager for HA: https://www.cloudera.com/documentation/enterprise/latest/topics/admin_cm_ha_overview.html Cloudera Director can set up an external database, say, in RDS, for use by a Cloudera Manager installation to be part of an eventual HA configuration. You would also need a load balance and a shared file system, neither of which Cloudera Director sets up for you natively, but an ELB and an EFS file system should do the job. If the goal is simply data preservation and not live failover, then use of RDS along with an EBS-backed AMI should be enough. If something goes wrong with a Cloudera Manager instance and it needs to be replaced, its EBS volume can be attached to a new instance and Cloudera Manager will come back up.
... View more
09-19-2017
08:12 AM
Hi Tomas79, First, thanks for your contributions to this thread as well as your suggestions! We do steer experienced users toward using configuration files and the bootstrap-remote CLI command vs. the UI, because the UI would get complex if we tried to add a checkbox or field or form for every Director feature into it. The Director server does have a full set of API endpoints that you can use to make updates to clusters that aren't easy or possible to do over the UI, so I recommend taking a look there. If you go to the /api-console URL for Director, there's an interactive facility for learning about the API and trying it out live. For example, there is an API endpoint for importing a configuration file directly into the server. It's documented here: https://www.cloudera.com/documentation/director/latest/topics/director_cluster_config.html#concept_lqt_2y1_x1b We don't have a corresponding configuration file export API endpoint yet, but you are not the first to suggest it, so be assured that it's on our wish list. In the meantime, the API can help you if you're willing to work with that. Director's single log is tough to navigate. Recent Director versions have added more context to lines in the log which make it feasible to filter relevant lines out. We've got some techniques documented here: https://www.cloudera.com/documentation/director/latest/topics/director_troubleshoot.html But I see room for more documentation. Specifically, at least as of 2.4: Each line includes a thread ID in square brackets. The ones starting with "p-" are for pipelines, Director's internal workflows, so you can follow one of those among all the other pipelines and other asynchronous tasks within Director. The fields following the thread ID are the unique (API) request ID, request method, and request URI that ultimately caused the activity being logged. You can work with the logback.xml file for the server to change the formatting, and perhaps even route logging to multiple files for easier comprehension (another ask that we've heard). Again, thanks for your feedback!
... View more