You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Jonathan Hurley (JIRA)" <ji...@apache.org> on 2015/06/19 18:39:01 UTC

[jira] [Created] (AMBARI-12022) Manual Rolling Upgrade Cannot Finalize Because Clients Reset Version On Restart

Jonathan Hurley created AMBARI-12022:
----------------------------------------

             Summary: Manual Rolling Upgrade Cannot Finalize Because Clients Reset Version On Restart
                 Key: AMBARI-12022
                 URL: https://issues.apache.org/jira/browse/AMBARI-12022
             Project: Ambari
          Issue Type: Bug
            Reporter: Jonathan Hurley
            Priority: Critical


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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)