Member since
02-18-2014
94
Posts
23
Kudos Received
23
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
3393 | 08-29-2019 07:56 AM | |
4137 | 07-09-2019 08:22 AM | |
2114 | 07-01-2019 02:21 PM | |
3619 | 03-19-2019 07:42 AM | |
2786 | 09-04-2018 05:29 AM |
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-07-2018
07:00 AM
Thanks Bill. Your advice really works.
... View more
06-05-2018
08:04 AM
Great! Thanks for the follow-up.
... View more
02-22-2018
08:57 AM
Thank you very much. It doesn't work with lp.bootstrap.packages.cmJavaPackages[0]: ".*=oracle-j2sdk1.8" as a property, I have this error in the logs when I try to use the CLI : org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'lp.bootstrap.packages-com.cloudera.launchpad.bootstrap.PackageIndex$ConfigProperties': Could not bind properties to PackageIndex.ConfigProperties (prefix=lp.bootstrap.packages, ignoreInvalidFields=false, ignoreUnknownFields=true, ignoreNestedProperties=false); nested exception is java.lang.UnsupportedOperationException So I put again lp.bootstrap.packages.cmJavaPackages: .*=oracle-j2sdk1.8 as property and it works fine. I misunderstood the Auto Strategy, maybe the documentation isn't very clear about it. I thought that this strategy forced Manager to deploy Java 8 on the cluster instances. It's ok with the Director_Managed Strategy, I have just Java 8 on my instances Thanks a lot !
... View more
02-15-2018
08:56 AM
Hi, I have follwed all the steps to install Spark2 in cloudera vm but getting following error when I am trying to Host spark2 parcel. CDH (5.8 and higher) parcel required for SPARK2 (2.2.0.cloudera2-1.cdh5.12.0.p0.232957) is not available. I am using CDH version : 5.12 and using http://archive.cloudera.com/spark2/parcels/2.2.0.cloudera2/ link for parcel. Please help me with the configurtion.
... 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
06-29-2017
09:01 AM
Hi Bill, thanks for the tips, setting "enable_api_debug: true" helped identifying the issue. It seems that the Oozie service is a requirement for Hue - After I included Oozie, the creation ran successfully.
... View more
06-26-2017
12:18 PM
Hi ztoth, The API doesn't support referencing an existing instance template when creating a new deployment through it. The entire instance template for the manager instance must be spelled out. To make this easier, you can GET the template for an existing deployment (not the deployment itself, but its template) that uses the desired instance template, and then copy out the details from the returned JSON. Going further, you can edit the JSON from that existing deployment template into what you POST for the new one, essentially rolling your own clone operation. If you do this, be sure to update the rest of the template to make it properly independent of the original: change the name of the deployment, change the ID for the manager virtual instance, update any bootstrap scripts, fill in the license and billing ID if used, and update database names and credentials for any pre-existing external databases. If you're also looking at reusing an external database server, once it's created it can be referenced inside external database templates and (existing) external databases in new deployment templates by its name, and it will be used as expected.
... View more