[
https://issues.apache.org/jira/browse/AMBARI-16107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yusaku Sako updated AMBARI-16107:
---------------------------------
Fix Version/s: (was: 2.5.0)
3.0.0
> Refactor technical debt to cleanup usage of params.version and other
> variables during RU/EU
> -------------------------------------------------------------------------------------------
>
> Key: AMBARI-16107
> URL: https://issues.apache.org/jira/browse/AMBARI-16107
> Project: Ambari
> Issue Type: Story
> Components: ambari-server
> Affects Versions: 2.4.0
> Reporter: Alejandro Fernandez
> Assignee: Alejandro Fernandez
> Fix For: 3.0.0
>
>
> The service scripts each use their own method of how to get the version that
> the stack is on and in many cases the confusion leads to bugs and regressions.
> This is because we use
> * /hostLevelParams/stack_version to represent the version that is "desired",
> such as 2.2 or 2.3
> * /commandParams/request_version (not sure what this is)
> * /commandParams/version for the version upgrading or downgrading to, which
> includes the build number
> * /commandParams/downgrade_from_version when in RU/DU and doing a downgrade,
> this includes the build number as well
> And the methods in hdp_select.py and conf_select.py tend to do hacky things.
> We need a consistent way of getting the different types of version (e.g.,
> only the major and minor, full with build number, the version during an
> RU/EU), and perhaps even put it in Script.py so that there's less confusion
> between scripts.
> Further, params.version was needed only during RU/EU restart commands, but
> now scripts are using it for checks even on fresh install and need to make
> comparisons like >= 2.3.4.0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
