> On Feb. 9, 2017, 7:17 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDescription.java,
> >  line 328
> > <https://reviews.apache.org/r/56394/diff/1/?file=1626642#file1626642line328>
> >
> >     Minor suggestions, 
> >     "default value of"
> >     
> >     ". Since the certificates/keystores/truststores in this path may affect 
> > the upgrade/downgrade process, it is recommended to manually move the 
> > certificates/keystores/truststores out of the conf folders and change the 
> > appropriate config values before proceeding.".
> >     
> >     Is this needed on all Ranger hosts?
> >     
> >     Can this be done instead with a custom python function?
> >     We already have such logic for components like Namenode that need to 
> > take a backup.
> >     
> >     Can this be handled during the RU/EU as a manual step just before 
> > Ranger?

Hi Alejandro,

Can this be done instead with a custom python function? We already have such 
logic for components like Namenode that need to take a backup.
    The motive is to just provide a check and a warning to the user to move 
existing certificate, keystore and truststore from the /etc/ranger/*/conf 
directories to another directories which may not be affected by RU/EU during 
upgrades/downgrades.Hence just a java check.

Can this be handled during the RU/EU as a manual step just before Ranger?
    If the user is in the middle of an upgrade and is shows a 
information/warning to change the configurations.Then user will need to 
downgrade first, then do the required changes in configuration and then again 
try for an upgrade. Hence have preferred a warning check prior to upgrade, 
rather than showing the information in the middle of the upgrade.

Is this needed on all Ranger hosts?
   Yes.


- Vishal


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


On Feb. 7, 2017, 4:27 p.m., Vishal Suvagia wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56394/
> -----------------------------------------------------------
> 
> (Updated Feb. 7, 2017, 4:27 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Gautam Borad, Mugdha 
> Varadkar, Oliver Szabo, Sumit Mohanty, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-19897
>     https://issues.apache.org/jira/browse/AMBARI-19897
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> As certificates/ keystores/ truststores present in /etc/ranger/*/conf path, 
> this may affect the upgrade scenarios, where user needs to manually move the 
> files to new conf directories.
> Hence users upgrading to new stacks should be warned on prior basis to do the 
> same manually (i.e move certificates/keystores/truststores out of conf 
> folder).
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDescription.java
>  8d8f540 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/RangerSSLConfigCheck.java
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.6.xml
>  8da11ff 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.6.xml 
> 01fc102 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.6.xml
>  046904b 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.6.xml 
> 70bb2ca 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.6.xml
>  5b8351b 
>   ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.6.xml 
> 2f07c97 
>   
> ambari-server/src/test/java/org/apache/ambari/server/checks/RangerSSLConfigCheckTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/56394/diff/
> 
> 
> Testing
> -------
> 
> Verified upgrade process after fresh install on Cent-os 6.
> 
> 
> Thanks,
> 
> Vishal Suvagia
> 
>

Reply via email to