> On March 22, 2017, 5:50 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
> > Lines 267 (patched)
> > <https://reviews.apache.org/r/57674/diff/1/?file=1665959#file1665959line267>
> >
> >     I'm still unclear on the problem.
> >     In Ambari Upgrade Catalog 212,
> >     override_hbase_uid should be removed from hbase-env
> >     since instead it is now controlled by override_uid in cluster-env.
> >     
> >     Looks like your logic may even change cluster-env's override_uid from 
> > true to false, so changing the behavior on existing clusters.
> >     
> >     Can you elaborate more?
> >     
> >     Also, this is going into trunk, so the chances of someone upgrading 
> > from Ambari 2.0 to 2.1 or higher usingn this version are extremely unlikely.

Hello Alejandro,

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.

Thanks.

Di


- Di


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57674/#review169742
-----------------------------------------------------------


On March 16, 2017, 2:15 a.m., Di Li wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57674/
> -----------------------------------------------------------
> 
> (Updated March 16, 2017, 2:15 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Tim Thorpe.
> 
> 
> Bugs: AMBARI-20461
>     https://issues.apache.org/jira/browse/AMBARI-20461
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> This is an issue specifically for custom stacks that 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.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
>  499c726 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog212Test.java
>  3f7bcc8 
> 
> 
> Diff: https://reviews.apache.org/r/57674/diff/1/
> 
> 
> Testing
> -------
> 
> unit tests. install an Ambari 2.1 cluster with my custom stack where HBase 
> does not have override_hbase_uid property. build Ambari rpm from trunk code, 
> run ambari upgrade, verify override_uid is set to false in cluster-env, so 
> that UIDs that I already set on my cluster are respected.
> 
> 
> Thanks,
> 
> Di Li
> 
>

Reply via email to