ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (AMBARI-12022) Manual Rolling Upgrade Cannot Finalize Because Clients Reset Version On Restart
Date Fri, 19 Jun 2015 17:59:00 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-12022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jonathan Hurley reassigned AMBARI-12022:
----------------------------------------

    Assignee: Jonathan Hurley

> 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
>            Assignee: Jonathan Hurley
>            Priority: Critical
>         Attachments: AMBARI-12022.patch
>
>
> 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)

Mime
View raw message