ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley" <jhur...@hortonworks.com>
Subject Review Request 35654: Manual Rolling Upgrade Cannot Finalize Because Clients Reset Version On Restart
Date Fri, 19 Jun 2015 17:05:26 GMT

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

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


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