> 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 > >
