You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Alejandro Fernandez (JIRA)" <ji...@apache.org> on 2016/02/03 01:16:39 UTC

[jira] [Updated] (AMBARI-14891) RU/EU should only delete configs on downgrade if source stack matches stack whose status is CURRENT

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

Alejandro Fernandez updated AMBARI-14891:
-----------------------------------------
    Attachment: AMBARI-14891.trunk.patch

> RU/EU should only delete configs on downgrade if source stack matches stack whose status is CURRENT
> ---------------------------------------------------------------------------------------------------
>
>                 Key: AMBARI-14891
>                 URL: https://issues.apache.org/jira/browse/AMBARI-14891
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.1.2
>            Reporter: Alejandro Fernandez
>            Assignee: Alejandro Fernandez
>             Fix For: 2.2.2
>
>         Attachments: AMBARI-14891.trunk.patch
>
>
> Saw a case with a customer in which they did the following.
> * Ambari 2.1.2
> * Rolling Upgrade from HDP 2.2 to 2.3.0.0 and skipped the Finalize step, so Ambari never called "Save DB State". Hence, the current stack version was still 2.2. They then modified the host_version and cluster_version records in the DB to mark HDP 2.3 as CURRENT.
> * Forgot to call ambari-server set-current-version
> * Registered and installed bits for HDP 2.3.4.0 and began another RU. After running into an issue, they decided to downgrade, which then completely removed the configs for the target stack (which is HDP 2.3!)
> In order to prevent deleting configs in cases where the user has modified the database, add stronger validation to FinalizeUpgradeAction so that we check that the request's source target stack equals the stack of the repo marked as CURRENT. In this case, they were 2.2 and 2.3, respectively.



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