[jira] [Created] (AMBARI-16107) Refactor technical debt to cleanup usage of params.version and other variables during RU/EU

["Alejandro Fernandez (JIRA)" <ji...@apache.org>]

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)