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] [Resolved] (AMBARI-20053) Remove the clusterconfigmapping Table
Date Tue, 21 Feb 2017 22:37:44 GMT

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

Mime
View raw message