Member since
09-26-2015
30
Posts
11
Kudos Received
2
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
2252 | 12-04-2015 04:28 PM | |
1228 | 11-06-2015 05:13 AM |
01-05-2016
07:09 PM
Sadly, no. In general, the smaller the blueprint the lesser the chances of breaking compatibility. Let me explain a bit as its not an intention to break backward compatibility. At a very high level, blueprint contains a) components and their layout, b) config settings that are Ambari influenced, c) config settings that are stack influenced, and d) templates for *-env/sh files etc.
In general,
* (a) remains backward compatible even through major releases. * (b) and (c) should remain backward compatible unless some config cleanup is performed e.g. created new configs for env/log4j files, cleaned up how heap sizes are specified - rare
* (d) includes scripts - these can go through bug fixes for any release So if you have a blueprint with primarily (a) and only the configs for which you want to over-write the default it should remain backward compatible. The biggest hurdle you can run into is that when you export a blueprint it does not export a minimal blueprint - rather a blueprint with all sections including (d).
... View more
12-28-2015
07:47 PM
I now see where the agent is calling initSchema... had missed it before. It fails when run from Ambari but succeeded when run from the cli. I'll accept an answer and drive on.
... View more
02-03-2016
03:50 PM
@kkane are you still having issues with this? Can you accept best answer or provide your own solution?
... View more
12-04-2015
04:21 PM
Since my question pertains to containers, prewarm is the correct answer but it is not the correct question so I will ask again.
... View more
12-03-2015
09:07 PM
@kkane important update on the above answer. At the moment hostgroup variables are not replaced by the actual hostnames, e.g. %HOSTGROUP::hg_master_node_3% is not replaced by c6603.ambari.apache.org. @Olivier Renault pointed this out to me today (Thanks!!). A RMP ticket has already been opened for this missing feature and the implementation is currently planned for one of the next major Ambari versions. One way to work around this missing piece is to replace the hostgroup variable with the actual hostname.
... View more
12-03-2015
08:53 PM
Ambari can only manage the principals and keytabs for the services managed by it. The pricipal and keytabs are actually provided as part of the configuration files with the stack definition.
For e.g. for Storm, looking at the stack , you can see - ....
"name": "storm_components",
"principal": {
"value": "${storm-env/storm_user}-${cluster_name}@${realm}",
"type": "user",
"configuration": "storm-env/storm_principal_name"
},
"keytab": {
"file": "${keytab_dir}/storm.headless.keytab",
"owner": {
"name": "${storm-env/storm_user}",
"access": "r"
},
.... Ambari does not support managing principals and keytabs of other components that are outside its purview.
... View more
11-24-2015
07:43 PM
1 Kudo
Correct Kris
... View more
11-23-2015
06:58 PM
great, I think it will be worth if you show screenshots in this thread for everyone else to use.
... View more
12-01-2015
02:04 AM
This would be a great scenario to figure out for my team. We have a java action that makes a JDBC connection to HS2. Can we somehow use the local token file in conjunction with the JDBC connection string to create a secure connection. I can't get that to work. Instead I'm using JAAS, which requires have a keytab file accessible on every node. I'd like to get away from that.
... View more