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