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)
