----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/35654/#review88559 -----------------------------------------------------------
Ship it! Ship It! - Nate Cole On June 19, 2015, 1:05 p.m., Jonathan Hurley wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/35654/ > ----------------------------------------------------------- > > (Updated June 19, 2015, 1:05 p.m.) > > > Review request for Ambari, Alejandro Fernandez, Nate Cole, and Tom Beerbower. > > > Bugs: AMBARI-12022 > https://issues.apache.org/jira/browse/AMBARI-12022 > > > Repository: ambari > > > Description > ------- > > Attempting Manual Maintenance Upgrade using these docs and cannot get step 9 > to work to get the clients to advertise/move to the new version. > > http://docs.hortonworks.com/HDPDocuments/Ambari-2.0.1.0/bk_upgrading_Ambari/content/_performing_a_manual_upgrade.html > > Here's the rundown of what's happening: > > - Every time we install a component, we must call hdp-select on it. This is > because when you install HDP 2.2, upgrade to HDP 2.3 and then add a new > service to your cluster, the symlink aren't bootstrapped by RPM since the > initial HDP 2.2 install already created them. It makes sense; you install a > component and you ensure it's on the right version after installing. > > - Client components, in someone's infinite wisdom, don't actually use their > "START" commands; instead when you start ZooKeeper, it will "INSTALL" > clients. This is actually in contrast to when you do a ZooKeeper RESTART > where both server and client components are sent the RESTART command. > > - The problem is that during a manual upgrade, we ask the users to manually > execute {{hdp-select}} to their new version and then start services to have > those services "broadcast" that new version back to Ambari. Once all services > are broadcasting the new version, we let the user manually "finalize". The > problem is that when you start a service, like ZK, the client is given the > INSTALL command, which does an {{hdp-select} _back_ to the old version. > > It's a chicken and an egg thing. We need to stop issuing INSTALL for a > clients on a service start; we should issue the START command and have > clients defer to > "configure". > > This was caused by AMBARI-9876 - I don't even think we need to do > {{set_version}} on {{install}} anymore since AMBARI-11891 now invokes > {{hdp-select set all ...}} after an upgrade. > > I think that AMBARI-9876 was attempting to fix a problem that we were causing > ourselves (ie not having the stack fully on the right version after an > upgrade). > > {quote} > Every time we install a component, we must call hdp-select on it. This is > because when you install HDP 2.2, upgrade to HDP 2.3 and then add a new > service to your cluster, the symlink aren't bootstrapped by RPM since the > initial HDP 2.2 install already created them. It makes sense; you install a > component and you ensure it's on the right version after installing. > {quote} > > That is no longer true since AMBARI-11891 resolved it. > > > Diffs > ----- > > ambari-agent/src/test/python/resource_management/TestScript.py 5107e1e > > ambari-common/src/main/python/resource_management/libraries/script/script.py > cf46ee2 > > Diff: https://reviews.apache.org/r/35654/diff/ > > > Testing > ------- > > Installed a 2.2 cluster and manuall upgraded to 2.2.y > Installed a 2.2. cluster, upgraded to 2.3 and then > - installed a new component on an existing host > - installed a new host > > OK > ---------------------------------------------------------------------- > Total run:762 > Total errors:0 > Total failures:0 > OK > > > Thanks, > > Jonathan Hurley > >
