[
https://issues.apache.org/jira/browse/AMBARI-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481994#comment-14481994
]
Alejandro Fernandez commented on AMBARI-10167:
----------------------------------------------
+ [~ncole], [~jhurley], [~dmitriusan], [~swagle], [~sumitmohanty], [~mahadev]
This feature has one breaking change. The older UpgradeCatalogs will have
run-time errors because the newer entity classes won't work against the older
database schemas.
After discussing with several team members, we need to make sure that Ambari
upgrades continue working as they do today.
This means that we may need a mixture of deprecated Entity classes and/or Query
Builders for the UpgradeCatalogs, instead of the current Entity classes.
Because all of the Upgrade Catalogs have unit tests that rely on
UpgradeCatalogHelper, we'll most likely need to disable the unit tests for the
older Upgrade Catalogs (1.5.1 through 2.0.0).
Thoughts?
> 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)
