@florianc Ambari uses a backend database to store all the configuration and changes after the initial install. It can be a derby, Mysql, Oracle, or MariaDB like it is in my case. Ambari 3.1.0 has around 111 tables that reference each other through primary and foreign keys so it's very easy to write an efficient SQL to output the desired information once you target the right tables. In a nutshell, the tables are intuitively named like alert_*, blueprint_* Cluster_* host_* _repo_* topology_* etc Logically the Cluster family should be our focus. I spun a single node cluster to demo this I have changed the knox.token.ttl because if you have ever worked with Knox Admin the UI is timesout so fast quite annoying. Below is an Ambari Ui and Database proof to confirm that all changes are persisted in the Ambari back end database. Note It has happened to me in cases of upgrade where the upgrade is stuck in incomplete status I have ad to go and physically change the status in the database to bring my cluster to life 🙂 MariaDB [(none)]> use ambari;
MariaDB [ambari]> show tables; I zeroed on the serviceconfig table MariaDB [ambari]> describe serviceconfig; From the output, I easily chose my rows MariaDB [ambari]> select service_name ,user_name,note from serviceconfig; I then added a filter to grab the version and note to validate it against my Ambari UI MariaDB [ambari]> select service_name,version ,user_name,note from serviceconfig; So here is the Ambari UI screenshot Voila the confirmation that changes doe in Ambari UI is persisted to whatever backend database is plugged Ambari. I have used the same technic to get blueprints : Happy hadooping
... View more
