ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMBARI-20053) Remove the clusterconfigmapping Table
Date Thu, 16 Feb 2017 20:52:41 GMT
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)

Mime
View raw message