> On March 31, 2016, 1:57 p.m., Jonathan Hurley wrote: > > Something doesn't seem right with this Jira. We should always be using the > > desired version when restarting a service. This would prevent the situation > > to begin with. > > > > But let's say we do nothing; then the following fields are affected: > > > > ``` > > "commandParams": { > > "version": "2.3.0.0-2557", > > }, > > ``` > > > > ``` > > "hostLevelParams": { > > "current_version": "2.3.0.0-2557", > > ``` > > > > But these values are only used in the context of an upgrade request. If an > > upgrade is suspended and a restart is issues, we do not use these values. > > So, it should have no impact on anything.
Right now the bug is that pausing an upgrade and restarting a service will use the version from the ClusterVersionEntity whose state is CURRENT. We do have a "desired_stack_id" in these tables: servicecomponentdesiredstate, hostcomponentdesiredstate, but the value will remain the same for an upgrade in the same stack. If I had more time to redesign this from scratch, I would add a column to the upgrade or the hostcomponentdesiredstate tables to indicate the version it should be using, which is then borderline Patch Upgrades. Given the time constraint, I wanted a simple solution, which is why I'm just checking for strings in the group and upgrade group item elements. - Alejandro ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45519/#review126305 ----------------------------------------------------------- On March 31, 2016, 2:07 a.m., Alejandro Fernandez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/45519/ > ----------------------------------------------------------- > > (Updated March 31, 2016, 2:07 a.m.) > > > Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jonathan > Hurley, Jayush Luniya, and Nate Cole. > > > Bugs: AMBARI-15637 > https://issues.apache.org/jira/browse/AMBARI-15637 > > > Repository: ambari > > > Description > ------- > > Currently, if RU/EU is paused, then restarting services manually will use the > version whose state is CURRENT. This means that services may be restarted on > the wrong version, preventing Ambari from correctly Finalizing the upgrade. > Instead, the logic should be as follows during Upgrade: > RU: always use to_version > EU: if haven't completed the action "UPDATE_DESIRED_STACK_ID", then use the > from_version, otherwise, use the to_version. > > During Downgrade, both should use the original version, which is actually the > to_version column in the upgrade table. > > THIS CODE REVIEW IS FOR BRANCH-2.2, I WILL CREATE A DIFFERENT ONE FOR TRUNK. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java > 1767b02 > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java > dd66dcc > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterStackVersionResourceProvider.java > ec49364 > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java > ef8a8d4 > > ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java > 5c8b7f3 > > ambari-server/src/main/java/org/apache/ambari/server/orm/dao/UpgradeDAO.java > 06f6ac1 > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostRoleCommandEntity.java > a12b204 > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/UpgradeEntity.java > fd866a1 > ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java > b49f566 > > ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java > 3493508 > > Diff: https://reviews.apache.org/r/45519/diff/ > > > Testing > ------- > > Verified it worked > > Assertions: > A: restart a service (should have version parameter, > B: run a service check (no version needed) > C: run HDFS Rebalance (should have version parameter). > > Test Cases: > 1. Before stack upgrade, run A, B, and C, which should all use the current > version > 2. EU, immediately click pause. Run A, B, and C, which should use the > original version if it exists > 3. EU, after the services have been stopped and the stack has been upgraded. > Run A, B, and C, which should use the new version since the services are now > to be started. > 4. EU, click downgrade and pause. Run A, B, C, which should use the original > version. > 5. RU, click pause whenever a manual task occurs. Run A, B, and C, which > should use the destination version. > 6. RU, click downgrade. Run A, B, and C, which should use the original > version. > > Unit Tests passed, > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 01:10 h > [INFO] Finished at: 2016-03-30T19:07:04-07:00 > [INFO] Final Memory: 130M/4052M > [INFO] > ------------------------------------------------------------------------ > > > Thanks, > > Alejandro Fernandez > >