> On Aug. 19, 2016, 1:10 p.m., Jonathan Hurley wrote:
> > The code in UpgradeHelper is still a bit fragile (even though now you're 
> > preventing the if-statement from failed. I say we either log the fact that 
> > we're not scheduling restarts or throw an exception:
> > 
> >           // Special case for NAMENODE when there are multiple
> >           if (service.serviceName.equalsIgnoreCase("HDFS") && 
> > component.equalsIgnoreCase("NAMENODE")) {
> > 
> >             // Rolling Upgrade requires first upgrading the Standby, then 
> > the Active NameNode.
> >             // Whereas NonRolling needs to do the following:
> >             //   NameNode HA:  Pick one to the be active, and the other the 
> > standby.
> >             //   Non-NameNode HA: Upgrade first the SECONDARY, then the 
> > primary NAMENODE
> >             switch (upgradePack.getType()) {
> >               case ROLLING:
> >                 if (!hostsType.hosts.isEmpty() && hostsType.master != null 
> > && hostsType.secondary != null) { 
> >                   // The order is important, first do the standby, then the 
> > active namenode.
> >                   LinkedHashSet<String> order = new LinkedHashSet<String>();
> > 
> >                   order.add(hostsType.secondary);
> >                   order.add(hostsType.master);
> > 
> >                   // Override the hosts with the ordered collection
> >                   hostsType.hosts = order;
> > 
> >                   builder.add(context, hostsType, service.serviceName,
> >                       svc.isClientOnlyService(), pc, null);
> >                 }
> >                 break;

I think it's appropriate to throw an Exception.  Will add.


- Nate


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


On Aug. 19, 2016, 12:55 p.m., Nate Cole wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51245/
> -----------------------------------------------------------
> 
> (Updated Aug. 19, 2016, 12:55 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-18216
>     https://issues.apache.org/jira/browse/AMBARI-18216
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> When doing RU on a secured cluster, the MasterHostResolver class is failing 
> the lookup of JMX. Ambari's SSL configuration must be used just like metrics 
> do.
> 
> Also adding some logging, and making sure that if we have 2 confirmed NN, 
> that we are always picking one to be the active and one to be the standby.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/MasterHostResolver.java
>  e6154d2 
>   ambari-server/src/main/java/org/apache/ambari/server/utils/HTTPUtils.java 
> cfb7128 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
>  55cb23b 
> 
> Diff: https://reviews.apache.org/r/51245/diff/
> 
> 
> Testing
> -------
> 
> Manual.  Automated pending.
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Reply via email to