Alejandro Fernandez created AMBARI-16107:
--------------------------------------------
Summary: 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: 2.4.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.4#6332)
