ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitro Lisnichenko" <dlysniche...@hortonworks.com>
Subject Re: Review Request 37682: [Preview] Stop-and-Start Upgrade: Move Configs out of Upgrade Pack
Date Mon, 31 Aug 2015 09:12:14 GMT


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


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