Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Ambari managed HDP cluster failed during automated installation using blueprint

Highlighted

Ambari managed HDP cluster failed during automated installation using blueprint

Contributor

I've managed to install the whole HDP solution by the installation wizard. During that part, I've changed most of the passwords from the database to service passwords. After successfully installed the whole cluster, I've managed to export the Ambari template via blueprint API. I did try to install the cluster one more time with the automatic deployment via blueprint through following Hortonworks manual. It didn't work. I was able to submit the request, but after 10 mins I found most of the installation parts failed.

I did check the logs, and I've noticed there are some issues around permission denied on MySQL database. I checked the blueprint template to find the passwords, but I found there is not any password included in the exported template. So I guess that caused an issue. I was wondering first, how can I export blueprint template with all of the passwords included at the first place? Second, how can I modify the template to store the required passwords for the installation? Like database passwords, service passwords, etc. I would be really grateful if somebody can guide me with any document or sample around setting all of these passwords.

4 REPLIES 4
Highlighted

Re: Ambari managed HDP cluster failed during automated installation using blueprint

Rising Star

Hi,

When a Blueprint is exported from a live cluster, the Blueprint processor will filter out any passwords found in the configuration. This is done as a security measure, in order to avoid leaking password data via the REST API in Ambari. There is no option in the export process to include the passwords in the exported Blueprint.

Generally, I would recommend not setting passwords in a Blueprint anyway. We usually recommend that any passwords be set in the Cluster Creation Template, which is the document that is POST-ed to create a cluster based on a Blueprint. Since the Cluster Creation Template is not persisted by the Ambari DB, its generally better to place passwords in that document instead. This also has the added benefit of making your Blueprint more portable, so that you could potentially create different clusters, with different credentials set, using the same Blueprint (but with modified Cluster Creation Template documents).

If you are setting up a development cluster (not for production), then you can just set the "default_password" property in the Cluster Creation Template, and this will cause the Blueprint processor to set any un-set passwords to that value.

Here's a link with more information on this:

https://cwiki.apache.org/confluence/display/AMBARI/Blueprints#Blueprints-ClusterCreationTemplateStru...

Again, I'd recommend only using this "default_password" feature in development clusters, and would avoid using this in production systems.

Hope this helps.

Highlighted

Re: Ambari managed HDP cluster failed during automated installation using blueprint

Contributor

Thanks, @rnettleton. I am using the automation in production so I am not able to use the default_password. Do you know the list of property_name I can use for this purpose? Guessing appropriate property_name would be an exusting job!

Highlighted

Re: Ambari managed HDP cluster failed during automated installation using blueprint

Rising Star

Hi @Ali,

Yes, it can be a tedious manual process to get the full list of required passwords.

I just checked the Ambari REST API for the stack definitions, but unfortunately there's no easy way to query the Stacks VIA the REST API to determine the list of required passwords.

Here's a simple command you can run against the stack definitions to get this information in a more convenient way. On your ambari-server machine, run the following commands:

1. cd /var/lib/ambari-server/resources

2. find . -name "*.xml" -print | xargs grep -A 5 -h "require-input=\"true\""

This command will search all .xml files in the stack definitions, and only match against files that include the "require-input" XML attribute. This attribute is used by the Blueprint processor to determine if a property is a required property. Each property is usually marked with a property-type of "PASSWORD" as well.

Here's a sample of the output for a property in this list:

"

<property require-input="true"> <name>oozie.service.JPAService.jdbc.password</name> <value/> <display-name>Database Password</display-name> <property-type>PASSWORD</property-type> <description>

"

As you can see above, this particular Oozie property is required and is also marked as a PASSWORD type, so if your Blueprint uses Oozie, this property would need to be set in the Cluster Creation Template (recommended) or Blueprint (not recommended).

This should at least allow you to get the list of properties beforehand, and include them in your Cluster Creation Template, rather than testing out deployments and waiting for the validation failures to report the missing properties one at a time.

I should note that I used Ambari 2.4 as my example, but this command should work with any version's stack definitions.

In order to provide a simple list to determine the properties, I added the grep "-h" flag in order to exclude the display of the filename where each property was found. If you need to know the filename, just remove the "-h" from the command line.

Sorry there isn't yet a simple way to do this, but hopefully this will save some time during your Blueprint development.

Hope this helps.

Highlighted

Re: Ambari managed HDP cluster failed during automated installation using blueprint

Rising Star

Hi @Ali, Did my most recent answer solve your problem?

If so, could you please accept the answer, just in case others might find this useful?

Thanks

Don't have an account?
Coming from Hortonworks? Activate your account here