> On May 10, 2016, 9:19 p.m., Nate Cole wrote:
> > Good grief.  I think this was my bad code.

Good grief is right - looks like a really hard merge between 2.2.2 and 2.4.0 
which caused this. The side-effect of my fix, the repo version ID problem, was 
unexpected. I would like to say that this would only be passed down on installs 
instead of all "actions", but the quicker fix here was to just ignore it in the 
agent response if the cluster is upgrading.


- Jonathan


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


On May 11, 2016, 12:17 p.m., Jonathan Hurley wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47202/
> -----------------------------------------------------------
> 
> (Updated May 11, 2016, 12:17 p.m.)
> 
> 
> Review request for Ambari, Dmitro Lisnichenko and Nate Cole.
> 
> 
> Bugs: AMBARI-16439
>     https://issues.apache.org/jira/browse/AMBARI-16439
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> There is a regression on the 2.4.0 line when restarting components during a 
> paused upgrade. 
> 
> STR:
> - Upgrade from HDP 2.3 to HDP 2.4, but don't finalize
> - Suspend the upgrade on the finalization step
> - Restart a ZooKeeper Server
> 
> The commands being sent down have 2.3.x instead of 2.4.0:
> ```
>     "commandParams": {
>         "service_package_folder": "common-services/ZOOKEEPER/3.4.5/package",
>         "script": "scripts/zookeeper_server.py",
>         "hooks_folder": "HDP/2.0.6/hooks",
>         "version": "2.3.4.0-3485",
>         "command_timeout": "1200",
>         "script_type": "PYTHON"
>     },
> 
>     "hostLevelParams": {
>         "current_version": "2.3.4.0-3485",
>         "custom_command": "RESTART",
>         "stack_version": "2.4",
> ```
> 
> The problem is located in {{ClusterImpl}} in how it calculates the upgrade. 
> In Ambari 2.2.2, it searched for upgrades, which also returned suspended 
> upgrades. In 2.4.0, it only looks at a currently running upgrade:
> 
> - 2.4.0
> `UpgradeEntity upgradeInProgress = getUpgradeEntity();`
> 
> 
> - 2.2.2
> `UpgradeEntity upgradeInProgress = this.getUpgradeInProgress();`
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/agent/ExecutionCommand.java
>  34a0918 
>   
> ambari-server/src/main/java/org/apache/ambari/server/agent/HeartbeatProcessor.java
>  c587e9f 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
>  6dbceba 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/listeners/upgrade/StackVersionListener.java
>  b14e9e5 
>   ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java 
> cf2c9aa 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
>  f38c25a 
>   
> ambari-server/src/test/java/org/apache/ambari/server/events/listeners/upgrade/StackVersionListenerTest.java
>  3a8b396 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterEffectiveVersionTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/47202/diff/
> 
> 
> Testing
> -------
> 
> Manual upgrade/downgrad/suspend test on a running cluster
> 
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 01:15 h
> [INFO] Finished at: 2016-05-11T00:08:57-04:00
> [INFO] Final Memory: 39M/410M
> [INFO] 
> ------------------------------------------------------------------------
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Reply via email to