[jira] [Created] (AMBARI-20053) Remove the clusterconfigmapping Table

["Jonathan Hurley (JIRA)" <ji...@apache.org>]

Jonathan Hurley created AMBARI-20053:
----------------------------------------

             Summary: Remove the clusterconfigmapping Table
                 Key: AMBARI-20053
                 URL: https://issues.apache.org/jira/browse/AMBARI-20053
             Project: Ambari
          Issue Type: Epic
          Components: ambari-server
    Affects Versions: trunk
            Reporter: Jonathan Hurley
            Assignee: Jonathan Hurley
            Priority: Critical
             Fix For: trunk


The {{clusterconfigmapping}} table seems to serve no purpose any longer now that we track service versions via the {{serviceconfig}} table. 

Take the following workflow:
- Create a new cluster; {{foo-site}} is created in {{clusterconfig}} at version 1 with tag {{INITIAL}}.
- Modify {{foo-site}}, creating a version 2. New entries are also created in both {{clusterconfig}} and {{clusterconfigmapping}}. The {{serviceconfig}} table updated to show v2.
- Revert back to v1 for the FOO service:
-- A new entry *is not* created in {{clusterconfig}} - in fact this table isn't touched.
-- A new entry *is* created in {{clusterconfigmapping}} which points to the original tag in {{clusterconfig}}
-- The {{serviceconfig}} table is updated to reflect v3, including the mappings back to the configs in {{clusterconfig}}.

In fact, it seems as though _nothing_ references {{clusterconfigmapping}}. There are two columns of interest in this table:
- {{selected}} - simply marks which config is active.
- {{user}} - the user who performed the action.

{{selected}} can be moved to {{clusterconfig}}, in addition to a new field to indicate the last time that a config was selected (for reversion of configurations). {{user}} is not used and the {{user}} column from the {{serviceconfig}} table can be used instead.

The proposal is to remove {{clusterconfigmapping}} entirely. When retrieving data from {{clusterconfig}}, the heavy columns which contain config data are lazily loaded from JPA, so there's no penalty for using this table as the source of truth for currently selected desired configs.

To Summarize:
- Remove the {{clusterconfigmapping}} table, which has redundant columns and causes nothing but headaches when it becomes out of sync with {{clusterconfig}}
- Change {{clusterconfig}} to track which configuration is selected and when the last time it was selected was
- Provide database upgrade scripts to convert existing databases

Some Thoughts:
- Configuration groups are problematic since they create configurations which are never "selected". They lack an entry in the {{clusterconfigmapping}} table.  These new configurations can also can problems when applying the "latest" configurations from a stack since they would appear newer than other configurations. For this reason, we'll keep track of if/when a configuration was selected.
- The heavy fields on {{ClusterConfigEntity}} must remain lazily loaded. More documentation should be added to cover this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)