@Brandon Wilson How can I remove a non-custom configuration parameter from a service in Ambari This is not possible to do solely via UI bit can be achieved with few manual steps Solution: Step1: Use configs.sh script provided on ambari-server host at location /var/lib/ambari-server/resources/scripts/configs.sh to delete a config property from a configuration file being managed and saved by Ambari in it's database Step2: Also remove those properties from static configuration file packaged with the service definition used by the stack that is deployed. This can be found at ambari-server host at location /var/lib/ambari-server/resources/common-services/ or inside stack located at /var/lib/ambari-server/resources/stacks/HDP/{version_name}/services/SPARK/configurations/* Step3: Restart ambari server process: ambari-server restart @Brandon Wilson if this is a valid use case that you feel should be addressed rather that doing a wrokaround than please create Apache Ambari Jira for this issue explaining your use-case. so someone can look into it and fix it in upcoming version of Ambari Also the two properties that you mentioned spark.yarn.principal and spark.yarn.keytab does not seem to be defined in the stack making them custom properties. can you please confirm your ambari version and under what section are these properties being exposed on service config page ? ... View more

@Brandon Wilson mqureshi's explanation is correct, technically, you can have unlimited number of snapshots in hbase, but it will put much pressure on hdfs. It would not only just occupy some disk space, but it would create a huge amount of hfiles that might slow down the NameNode. Let's assume that you have a 10-CF HTable with 50k regions, each CF has 5 hfiles in average, which means you would have totally 2.5million hfiles for this single table. The first time you create a snapshot, all 2.5m hfiles will be referenced. When you do another snapshot in the next day(after some routine compactions, of course), another 2 or more million new hfiles will probably be referenced. Remember: old hfiles would not be removed until the snapshot is removed. In this case, you will get more than 15 million referenced hfiles after a week, which would be a really bad news for namenode. ... View more

@Brandon Wilson Sadly no. It's all or nothing. As long as you can reach that ResourceManager UI, you see it all. There is no segregation. ResourceManager is really not user-aware. You would need another layer in top of that capable to show only some parts of what ResourceManager UI provides. This could be something that maybe Ranger could implement, but it would require some major redo of that ResourceManagerUI. I don't think that is that configurable. Just check the code for it. ... View more

The boostrap process restarts NiFi when the main NiFi process dies. An easy test is to start a new NiFi and then kill -9 the main process and you'll immediately see it come back with a new pid. OOM would probably be tricky because a lot of times the Java process does not die when encountering an OOM and sticks around in some bad state. ... View more

@Ted Yu Ambari does not automatically adjust memory for any components. You should use the companion scripts to calculate and tune the heap memory for each component. Also, you should try using Smartsense, which can identify signs of potential issues and provide recommendations for better tuning of HDP components. Neither Ambari, nor Smartsense will make any automatic adjustment to the configuration of HDP components. There are defaults values for the configuration ( which must be manually tuned as per cluster usage ). ... View more