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

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

     [ https://issues.apache.org/jira/browse/AMBARI-20053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Hurley resolved AMBARI-20053.
--------------------------------------
    Resolution: Fixed

> 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)