> On Aug. 27, 2015, 5:40 p.m., Jonathan Hurley wrote: > > ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java, > > lines 244-252 > > <https://reviews.apache.org/r/37682/diff/5/?file=1056032#file1056032line244> > > > > I'm still not a fan of the ordering being used as the main way of > > orchestrating the upgrades. What if there is a particular order the > > configurations need to be executed in? What if some happen in the <order> > > element and some in <processing>. Should we be using IDs instead and have > > an explicit link between upgrade pack and config pack.
We decided to move all config tasks from upgrade pack to a separate file. When executing cross-stack upgrade (like 2.2->2.4), we are not going to parse and execute intermediate upgrade packs, but only apply config changes from `upgrade-config-changes-*.xml` files for installed services. Service ordering for config application is going to be borrowed from target upgrade pack. So ID/linking approach may be not too flexible when upgrading over few stacks (we would have to be careful with config change coherense in different upgrade packs for the same stack). So to handle such cases I'd vote for using per-service config change priority (float-point value). Adding per-service config change priority (valid in scope of a single stack) should allow us to apply config changes in arbitrary order when executing changes. Let's discuss this solution on sync today if needed. > On Aug. 27, 2015, 5:40 p.m., Jonathan Hurley wrote: > > ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.2.xml, > > line 467 > > <https://reviews.apache.org/r/37682/diff/5/?file=1056036#file1056036line467> > > > > But what about cases where there a configuration done in the <order> > > section? How about implementing a virtual "apply all config changes for service" task type to handle this use case? When executing cross-stack upgrade (like 2.2->2.4), we are not going to parse and execute intermediate upgrade packs, but only apply config changes for installed services. So, when executing upgrade pack for target stack, "apply all config changes for service" task would apply all config changes for service defined at `upgrade-config-changes-*.xml` files for intermediate stacks. Does this approach sound good? - Dmitro ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37682/#review96707 ----------------------------------------------------------- On Aug. 27, 2015, 3:08 p.m., Dmitro Lisnichenko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/37682/ > ----------------------------------------------------------- > > (Updated Aug. 27, 2015, 3:08 p.m.) > > > Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan > Hurley, and Nate Cole. > > > Bugs: AMBARI-12700 > https://issues.apache.org/jira/browse/AMBARI-12700 > > > Repository: ambari > > > Description > ------- > > The configs need to move out of the Upgrade Packs and into their own file. > This will make it easier to maintain, and clearer since there will not be any > dups. > > Since it is going to be a massive change, it would be great to get early > feedback. Code is not complete (still full of TODOs and does not even build) > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/api/services/AmbariMetaInfo.java > 4afa9b0 > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java > fa743be > > ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/ConfigureAction.java > c717582 > > ambari-server/src/main/java/org/apache/ambari/server/stack/StackDefinitionDirectory.java > 8f81b5a > > ambari-server/src/main/java/org/apache/ambari/server/stack/StackDirectory.java > 89c10c6 > ambari-server/src/main/java/org/apache/ambari/server/stack/StackModule.java > 4b88aff > ambari-server/src/main/java/org/apache/ambari/server/state/StackInfo.java > 2aa89cc > > ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java > 3e25d01 > > ambari-server/src/main/java/org/apache/ambari/server/state/stack/UpgradeConfigChangesDescriptor.java > PRE-CREATION > > ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java > 8361ea6 > > ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/ConfigureTask.java > 8361ea6 > ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.2.xml > 9b7848f > > ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/ConfigureActionTest.java > 93e29b5 > > ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java > f7898ee > > ambari-server/src/test/java/org/apache/ambari/server/state/stack/UpgradePackTest.java > a73775f > > ambari-server/src/test/resources/stacks/HDP/2.2.0/upgrades/upgrade-config-changes-2.2.xml > PRE-CREATION > > Diff: https://reviews.apache.org/r/37682/diff/ > > > Testing > ------- > > just published preview of changes > > > Thanks, > > Dmitro Lisnichenko > >
