Team… We will need to move some Ambari-wide configurations from the ambari.properites file to the Ambari database. This is so we can manage them from the Ambari User Interface of REST API. When we do this, we gain the auditing and versioning features we have with cluster- and service-level configurations.
Currently the cluster- and service-level configurations are stored in the clusterconfig table, which looks something like: clusterconfig config_id BIGINT NOT NULL version_tag VARCHAR(255) NOT NULL version BIGINT NOT NULL type_name VARCHAR(255) NOT NULL cluster_id BIGINT NOT NULL stack_id BIGINT NOT NULL selected SMALLINT NOT NULL DEFAULT 0 config_data TEXT NOT NULL config_attributes TEXT create_timestamp BIGINT NOT NULL unmapped SMALLINT NOT NULL DEFAULT 0 selected_timestamp BIGINT NOT NULL DEFAULT 0 A bunch of the work has been done to store Ambari-wide configurations in the database as part of AMBARI-21307 (https://issues.apache.org/jira/browse/AMBARI-21307). However, I am not sure if the implementation is something we wish to pursue. The idea in the patch (which is not totally complete) is to create a common configuration table to be shared by Ambari-, cluster-, and service-level configurations while pulling the fields needed by each level out into its own table. Using foreign keys and inherited entity classes the data would be merged together to generate the requested configuration data. Continuing with what is proposed (but not completed) in the patch, the following tables would exist: configuration: configuration_id BIGINT NOT NULL version_tag VARCHAR(255) NOT NULL version BIGINT NOT NULL name VARCHAR(255) NOT NULL selected SMALLINT NOT NULL DEFAULT 0 config_data TEXT NOT NULL config_attributes TEXT create_timestamp BIGINT NOT NULL selected_timestamp BIGINT NOT NULL DEFAULT 0 cluster_configuration: configuration_id BIGINT NOT NULL cluster_id BIGINT NOT NULL stack_id BIGINT NOT NULL unmapped SMALLINT NOT NULL DEFAULT 0, ambari_configuration: configuration_id BIGINT NOT NULL In each table, configuration_id would be the primary key. In the cluster_configuration and ambari_configuration tables, the configuration_id would also be a foreign key into the configuration table. Other option is to scrap that idea, leave the clusterconfig table as is, and create a separate ambariconfig table that looks similar and manage the tables with a separate set of entity objects. I am open for either way. Originally, I liked the first option; but it appears (via JPA docs) that it may have performance issues due to the table join operation needed whenever a configuration is retrieved from the database. Thoughts? Thanks, Rob
