[
https://issues.apache.org/jira/browse/AMBARI-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Fernandez updated AMBARI-10167:
-----------------------------------------
Description:
Deleting a host from the UI only removes it from the mapping to a cluster.
The host still exists at the hosts endpoint, and all of the historic data
maintains intact; config overrides, config groups, host state, host version,
host role command logs, etc.
This causes two problems.
1. If a host is removed from a cluster and its underlying environment changes
(OS, IP, network card, etc), and is re-added to the cluster, then it still
maintains the old information that is incorrect.
2. If host x dies, and is removed from the cluster, there is no way for a new
host to take over its hostname.
*Expectation in Ambari 2.1.0*
Deleting a host should be clean, i.e., it should delete all configuration and
historic records.
Because renaming a host requires a more complicated workflow, so it will have
to be done manually by the user (see instructions in A1).
Lastly, Ambari will require ambari-agent to be stopped before the host can be
deleted.
*Tables:*
10 tables have foreign keys to the host_name in the hosts table:
1. hostcomponentstate
2. hostcomponentdesiredstate
3. hoststate
4. host_version
5. host_role_command
6. request_operation_level
7. hostconfigmapping
8. configgrouphostmapping
9. kerberos_principal_host
10. clusterhostmapping
*Migration:*
hosts table: Insert a new auto-increment PK, called host_id
For each table,
1. add a column, host_id
2. populate it with the value from the hosts table
3. add the FK relationship
4. remove the old FK from the host_name column
5. remove the old host_name column
This will require changes to UpgradeCatalog210.java to perform the schema
changes as part of the upgrade to Ambari 2.1.0. Further, this will need to be
tested on the four database installations that Ambari supports: internal
Postgres, external Postgres, Oracle, MySQL.
was:
Deleting a host from the UI only removes it from the mapping to a cluster.
The host still exists at the hosts endpoint, and all of the historic data
maintains intact; config overrides, config groups, host state, host version,
host role command logs, etc.
This causes two problems.
1. If a host is removed from a cluster and its underlying environment changes
(OS, IP, network card, etc), and is re-added to the cluster, then it still
maintains the old information that is incorrect.
2. If host x dies, and is removed from the cluster, there is no way for a new
host to take over its hostname.
> Delete a host from Ambari cluster is not clean; fails to re-add the same host
> -----------------------------------------------------------------------------
>
> Key: AMBARI-10167
> URL: https://issues.apache.org/jira/browse/AMBARI-10167
> Project: Ambari
> Issue Type: Story
> Components: ambari-server
> Affects Versions: 1.7.0
> Reporter: Alejandro Fernandez
> Assignee: Alejandro Fernandez
> Fix For: 2.1.0
>
>
> Deleting a host from the UI only removes it from the mapping to a cluster.
> The host still exists at the hosts endpoint, and all of the historic data
> maintains intact; config overrides, config groups, host state, host version,
> host role command logs, etc.
> This causes two problems.
> 1. If a host is removed from a cluster and its underlying environment changes
> (OS, IP, network card, etc), and is re-added to the cluster, then it still
> maintains the old information that is incorrect.
> 2. If host x dies, and is removed from the cluster, there is no way for a new
> host to take over its hostname.
> *Expectation in Ambari 2.1.0*
> Deleting a host should be clean, i.e., it should delete all configuration and
> historic records.
> Because renaming a host requires a more complicated workflow, so it will have
> to be done manually by the user (see instructions in A1).
> Lastly, Ambari will require ambari-agent to be stopped before the host can be
> deleted.
> *Tables:*
> 10 tables have foreign keys to the host_name in the hosts table:
> 1. hostcomponentstate
> 2. hostcomponentdesiredstate
> 3. hoststate
> 4. host_version
> 5. host_role_command
> 6. request_operation_level
> 7. hostconfigmapping
> 8. configgrouphostmapping
> 9. kerberos_principal_host
> 10. clusterhostmapping
> *Migration:*
> hosts table: Insert a new auto-increment PK, called host_id
> For each table,
> 1. add a column, host_id
> 2. populate it with the value from the hosts table
> 3. add the FK relationship
> 4. remove the old FK from the host_name column
> 5. remove the old host_name column
> This will require changes to UpgradeCatalog210.java to perform the schema
> changes as part of the upgrade to Ambari 2.1.0. Further, this will need to be
> tested on the four database installations that Ambari supports: internal
> Postgres, external Postgres, Oracle, MySQL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
