ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alejandro Fernandez" <afernan...@hortonworks.com>
Subject Re: Review Request 37946: Stop-and-Start Upgrade: If using HDP 2.x, can only register repo for HDP 2.y since need an upgrade pack to support it
Date Wed, 02 Sep 2015 23:51:12 GMT


> On Sept. 2, 2015, 1:37 p.m., Jonathan Hurley wrote:
> > I'm a bit confused as to why we need to verify that creation of a repository needs
to have an upgrade pack. For things like patch upgrades, there won't be an upgrade pack, but
a new repository will be created.
> 
> Alejandro Fernandez wrote:
>     This was mainly for RU and Stop-the-World, in which it doesn't make sense to register
a repo for a version if no upgrade pack supports its.
>     However, you can also argue this case. Assume that the customer is on HDP 2.2, and
HDP 2.4 is already out, and we only support upgrade packs for HDP 2.2->2.3, and 2.3->2.4.
In this case, the user should perhaps be allowed to register both repos, and then perform
2 RUs, first from 2.2->2.3, and then 2.3->2.4
> 
> Alejandro Fernandez wrote:
>     I'm ok with keeping D.G.'s logic for now, at least until patch upgrades comes out.
> 
> Dmytro Grinenko wrote:
>     not realy uderstand, why "2.2->2.3, and then 2.3->2.4" it looks more risky
and a lot more slow, than 2.2->2.4, isn't?

The issue with supporting 2.2->2.4 in one shot is that it opens us to bugs and more complexity
with maintaining config changes in deletes (and then a readd), renames, and transformations.

Jumping ine one shot would mean that we have a file for 2.2->2.4, and another for 2.3->2.4
(since this is also valid for some customers).

So if a property is deleted in 2.4, it has to be edited in both of those files, which is a
small maintenance cost.

What's riskier is the following: consider a property that is transformed with some function,
say f(x) in HDP 2.2->2.3, and g(x) in HDP 2.3->2.4. This means that a customer that
did HDP 2.2->2.3, and then after a couple of months did HDP 2.3->2.4, ended up with
g(f(x)).
Now, if the customer wants to do HDP 2.2->2.4 in one shot, we need to have a transformation
h(x) such that h(x) = g(f(x)), which may not be easy.

Another risky one is deletes and re-adds. Assume that property x is deleted in HDP 2.2->2.3,
and then the property name is added again in HDP 2.3->2.4.
A customer that did these two upgrades in seperate RUs would have the newer value coming from
HDP 2.4 since it didn't exist in their last upgrade (which was from HDP 2.3).
But if did HDP 2.2->2.4 in one shot, and the user happened to edit the property in HDP
2.2, then we will preserve their changes and not update it with the value in HDP 2.4.

My point is that no matter what steps the customer takes to get from x to y, the end result
should be the same, and that is only accomplished with an intermediate step.


- Alejandro


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


On Aug. 31, 2015, 1:54 p.m., Dmytro Grinenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37946/
> -----------------------------------------------------------
> 
> (Updated Aug. 31, 2015, 1:54 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmitro Lisnichenko, Jonathan Hurley,
and Nate Cole.
> 
> 
> Bugs: AMBARI-12934
>     https://issues.apache.org/jira/browse/AMBARI-12934
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> In Ambari 2.2.0, we'll need to support Stop-and-Start Upgrade from HDP 2.x -> 2.y.
> This means that if the user is still on HDP 2.x, the only upgrade pack possible will
be Stop-and-Start Upgrade to HDP 2.y, so it doesn't make sense to allow the user to register
a repo for any version except HDP 2.y.
> During repo_version creation, we need to ensure that the version being installed has
an upgrade pack that will allow upgrading to it.
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RepositoryVersionResourceProvider.java
f1fa3bf 
>   ambari-server/src/main/java/org/apache/ambari/server/state/stack/UpgradePack.java 79b8eb5

>   ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/RepositoryVersionHelper.java
2e17cf4 
>   ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RepositoryVersionResourceProviderTest.java
442bcb2 
> 
> Diff: https://reviews.apache.org/r/37946/diff/
> 
> 
> Testing
> -------
> 
> tests passed
> 
> 
> Thanks,
> 
> Dmytro Grinenko
> 
>


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