ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Di Li" <d...@ca.ibm.com>
Subject Re: Review Request 35352: AMBARI-11810: Rolling upgrade does not run pre-upgrade checks against non-HDP stack
Date Thu, 09 Jul 2015 14:27:19 GMT


> On July 8, 2015, 2:29 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/checks/AbstractCheckDescriptor.java,
line 110
> > <https://reviews.apache.org/r/35352/diff/2/?file=991456#file991456line110>
> >
> >     So basically this is saying that if the request source/target stack are the
same brand (HDP, Bigtop, PHD, etc) then always run the check as long as they are not the same
as the check's source stack.
> >     
> >     So, given StackA-1, StackA-2 and StackB-1, always run this check if using StackB
if the check is meant for StackA?
> >     
> >     I mean, I guess that would allow checks to run in the event that you are using
a different stack. But nothing guarantees that the actual concrete check will work properly;
this only ensures that it is run.
> >     
> >     Are you trying to unblock something for Ambari 2.1.0 because this seems like
a short circuit in order to get checks to run on other stacks.
> >     
> >     If not, I would suggest this: put together a design proposal or a new patch
that moves all of this logic out of the Java code and into the upgrade pack. This way, you
can decorate the upgrade packs to define which stacks the checks are valid for.

hello Jonathan,

Thank you for the review.

"sourceStackName" is from the "sourceStackId" StackId object, the "sourceStackId" object is
a hardcoded value as HDP-2.2, meaning "sourceStackName" is always "HDP" for now.

So for the two conditionas in the IF clause that you highlighted
1. "!sourceStackName.equals(requestSourceStackName)" makes sure the code is for non HDP stack
2. "requestSourceStackName.equals(requestTargetStackName)" makes sure the stacks being compared
has the same stack name (passed from the UI side), so I don't think the StackA-1 vs StackB-1
use case would pass the check here.

Once the code goes into the IF clause, it checks the versions of the two stacks to make sure
the target version is newer than the source's

I am trying to make Ambari capable of running RU precheck for non HDP stacks. this is not
required for the HDP 2.3 release, but there are use cases where Ambari runs against non-hdp
stacks.

If what I said doesn't really make such sense from Ambari design point of view, please do
let me know as I am new to Ambari. Also, Could you please give me more points on your suggestion
of moving the logic to the upgrade pack?

Thank you.

Di


- Di


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


On July 3, 2015, 8:50 p.m., Di Li wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/35352/
> -----------------------------------------------------------
> 
> (Updated July 3, 2015, 8:50 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Nate Cole.
> 
> 
> Bugs: AMBARI-11810
>     https://issues.apache.org/jira/browse/AMBARI-11810
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> All the rolling upgrade pre-checks may still need to run against a non-HDP stack. Use
this JIRA to make the check runnable based on properties (rollingupgrade.stack, rollingupgrade.version)
set in the /etc/ambari-server/conf/ambari.properties. Still default to HDP and 2.2.4.2 if
the properties do not exist.
> 
> org.apache.ambari.server.checks.AbstractCheckDescriptor compares stack against hardcoded
StackInfo "HDP-2.2". the stack name and version info can be externalized into the /etc/ambari-server/conf/ambar.properties
in order to support non-HDP stacks.
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/checks/AbstractCheckDescriptor.java
8cabf29 
>   ambari-server/src/test/java/org/apache/ambari/server/checks/AbstractCheckDescriptorTest.java
4834cee 
> 
> Diff: https://reviews.apache.org/r/35352/diff/
> 
> 
> Testing
> -------
> 
> Added new unit tests
> 
> Manual test
> 1. Verify that without the fix, no rolling upgrade prechecks ran, the Ambari web UI popped
open a dialog showing all the rolling upgrade precheck as failures.
> 2. with the fix, the prechecks ran, I got to see a warning dialog suggesting me to enable
HA for hive metastore as well as showing me hive/hadoop properties that RU will modify.
> 
> 
> Thanks,
> 
> Di Li
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message