[
https://issues.apache.org/jira/browse/AMBARI-20461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Di Li updated AMBARI-20461:
---------------------------
Description:
Custom stacks may not have override_hbase_uid property in hbase-env.xml, in
this case, override_uid is currently set to true by Ambari's auto merge logic.
it should be set to false when upgrading Ambari 2.1 to 2.2 or newer with custom
stacks in order to respect the existing UID customers already set on their
clusters.
This is for upgrading a third party Ambari/stack distribution from Ambari
version 2.1.0 to Ambari trunk. HDP stacks do not have this issue.
The HBase in my own stack did not have 'override_hbase_uid' when I released it
with AMbari 2.1.0. Current code (without my change) will merge override_uid
with default value true (defined in cluster-env) when I upgrade Ambari to
trunk. For clusters that used UID less than 1000, override_uid=true causes
Ambari to update the UIDs, and servers will fail to restart.
My code change is in UpgradeCatalog212 and only runs if "override_hbase_uid"
does not exist (either it doesn;t exist, or the entire hbase-env doesn;t
exist). This means that my code change only affects old Ambari 2.1.0 or Ambari
2.1.1 when upgrading them to Ambari trunk. If a cluster has Ambari 2.2.x
(override_uid was added in Ambari 2.1.2), UpgradeCatalog212 does not run, so my
logic does not run, respecting whatever override_uid the cluster always uses.
If a cluster is with HDP stacks and on Ambari 2.1.0, the current logic in
UpgradeCatalog212 runs, so my logic still doesn;t affect it.
was:Custom stacks may not have override_hbase_uid property in hbase-env.xml,
in this case, override_uid is currently set to true by Ambari's auto merge
logic. it should be set to false when upgrading Ambari 2.1 to 2.2 or newer with
custom stacks in order to respect the existing UID customers already set on
their clusters.
> override_uid should set to false when upgrading Ambari 2.1 to 2.2 or newer
> with custom stacks
> ---------------------------------------------------------------------------------------------
>
> Key: AMBARI-20461
> URL: https://issues.apache.org/jira/browse/AMBARI-20461
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: trunk
> Reporter: Di Li
> Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-20461.patch
>
>
> Custom stacks may not have override_hbase_uid property in hbase-env.xml, in
> this case, override_uid is currently set to true by Ambari's auto merge
> logic. it should be set to false when upgrading Ambari 2.1 to 2.2 or newer
> with custom stacks in order to respect the existing UID customers already set
> on their clusters.
> This is for upgrading a third party Ambari/stack distribution from Ambari
> version 2.1.0 to Ambari trunk. HDP stacks do not have this issue.
> The HBase in my own stack did not have 'override_hbase_uid' when I released
> it with AMbari 2.1.0. Current code (without my change) will merge
> override_uid with default value true (defined in cluster-env) when I upgrade
> Ambari to trunk. For clusters that used UID less than 1000, override_uid=true
> causes Ambari to update the UIDs, and servers will fail to restart.
> My code change is in UpgradeCatalog212 and only runs if "override_hbase_uid"
> does not exist (either it doesn;t exist, or the entire hbase-env doesn;t
> exist). This means that my code change only affects old Ambari 2.1.0 or
> Ambari 2.1.1 when upgrading them to Ambari trunk. If a cluster has Ambari
> 2.2.x (override_uid was added in Ambari 2.1.2), UpgradeCatalog212 does not
> run, so my logic does not run, respecting whatever override_uid the cluster
> always uses. If a cluster is with HDP stacks and on Ambari 2.1.0, the current
> logic in UpgradeCatalog212 runs, so my logic still doesn;t affect it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
