[jira] [Comment Edited] (AMBARI-11098) Fast Offline Stack Upgrades (better than rolling upgrades in many cases)

["Rahul Pathak (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMBARI-11098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117612#comment-15117612 ] 

Rahul Pathak edited comment on AMBARI-11098 at 6/6/16 5:21 AM:
---------------------------------------------------------------

[~harisekhon]

This can be closed I guess. It has been fixed in Ambari 2.2

First you need to upgrade ambari to 2.1.0 and then to 2.2.0

Ambari 2.2.0 has express upgrade feature which is what you have asked for.


was (Author: rahulp):
First upgrade ambari to 2.1.0 and then to 2.2.0

Ambari 2.2.0 has express upgrade feature

> Fast Offline Stack Upgrades (better than rolling upgrades in many cases)
> ------------------------------------------------------------------------
>
>                 Key: AMBARI-11098
>                 URL: https://issues.apache.org/jira/browse/AMBARI-11098
>             Project: Ambari
>          Issue Type: New Feature
>          Components: ambari-server, stacks
>    Affects Versions: 2.0.0
>         Environment: HDP 2.2
>            Reporter: Hari Sekhon
>            Priority: Critical
>
> Feature Request to allow fast offline stack upgrades / downgrades instead of the only option being slow rolling upgrades.
> Currently rolling upgrades take a very, very long time and there many hiccups in the process (pages of jiras on rolling upgrade problems).
> For many people's clusters which are mainly doing batch analytics / data warehouse reports etc it's simply not necessary to try for the 100% uptime and waste all day(s) babysitting and rolling back every time there is any problem in the rolling upgrade, this in fact wastes a huge amount of operator time and blocks users getting their bug fixes or new features they need.
> Operators should have the option of doing a fast and simple offline upgrade/downgrade:
> 1. Shut down entire cluster
> 2. Upgrade (or Downgrade) stack in parallel quickly across all nodes
> 3. Start up whole cluster again on different version
> This is the difference between taking 30 mins or taking 8 hours to do an upgrade/downgrade and is preferable to only being allowed to do rolling upgrades. I've even done fast offline upgrade on another vendor in prod because sometimes it's just the better thing to do to get things finished quickly and allow users to utilize the fixes the upgrades provides immediately, especially where they're blocked on needing that upgrade or if wanting to very quickly roll back to a previous version after discovering some issue later (please also add arbitrary downgrades AMBARI-11097).
> This would make testing much much faster and easier, and gives users access to new features or bug fixes they may be blocked on more quickly, rather than having to be blocked behind the long rolling upgrade process.



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