[
https://issues.apache.org/jira/browse/AMBARI-21854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16173207#comment-16173207
]
Hudson commented on AMBARI-21854:
---------------------------------
FAILURE: Integrated in Jenkins build Ambari-branch-2.6 #253 (See
[https://builds.apache.org/job/Ambari-branch-2.6/253/])
AMBARI-21854. Adapt Repository Files For Existing Deployments (dgrinenko
(dlysnichenko:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=412c6cac4416cb676046dd6792ccb962441febf5])
* (edit)
ambari-common/src/main/python/resource_management/libraries/script/script.py
* (edit) ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql
* (edit)
ambari-server/src/main/resources/custom_actions/scripts/install_packages.py
* (edit) ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql
* (edit) ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql
* (edit)
ambari-common/src/main/python/resource_management/libraries/functions/repository_util.py
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariActionExecutionHelper.java
* (edit)
ambari-common/src/main/python/resource_management/core/providers/package/apt.py
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/RepositoryVersionHelper.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
* (edit)
ambari-common/src/main/python/resource_management/core/providers/package/__init__.py
* (edit)
ambari-common/src/main/python/resource_management/core/providers/package/zypper.py
* (edit) ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/agent/CommandRepository.java
* (edit) ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/RepositoryVersionEntity.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog260.java
* (edit) ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/agent/ExecutionCommand.java
* (edit)
ambari-common/src/main/python/resource_management/core/providers/package/yumrpm.py
> Adapt Repository Files For Existing Deployments
> -----------------------------------------------
>
> Key: AMBARI-21854
> URL: https://issues.apache.org/jira/browse/AMBARI-21854
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
> Affects Versions: 2.6.0
> Reporter: Jonathan Hurley
> Assignee: Dmytro Grinenko
> Priority: Blocker
> Fix For: 2.6.0
>
>
> The recent changes in repository creation and management (AMBARI-20871,
> AMBARI-21719, AMBARI-21398) has caused a regression with previously installed
> packages. Using RPM as an example, consider the following case:
> - A version of Ambari is installed which writes out a repo file for HDP. This
> file could be named anything and may vary depending on the version of Ambari
> being used. It could be {{hdp.repo}}, {{hdp-2.6.repo}}, or really any
> variation. The point is that it's not predictable.
> - The repo ID inside of the file can also be anything. In some cases it may
> be "HDP-2.6.2.0" or "HDP-2.6.2.0-193". But once again, the point is that it's
> not predictable.
> - What is known is that packages previously installed with this repo are now
> associated with it permanently:
> {code}
> [root@c6401 yum.repos.d]# yum list installed | grep hive2
> hive2_2_6_2_0_193.noarch 2.1.0.2.6.2.0-193
> @HDP-2.6.2.0-193
> hive2_2_6_2_0_193-jdbc.noarch 2.1.0.2.6.2.0-193
> @HDP-2.6.2.0-193
> {code}
> - Ambari has now changed the way in which we create repo files and the naming
> scheme we use for the repo ID. Consider a fresh installation of Ambari 2.6:
> {code:title=/etc/yum.repos.d/ambari-hdp-1.repo}
> [HDP-2.5-repo-1]
> name=HDP-2.5-repo-1
> baseurl=http://repo.ambari.apache.org/hdp/centos6/HDP-2.5.0.0-1237
> path=/
> enabled=1
> gpgcheck=0
> [HDP-UTILS-1.1.0.21-repo-1]
> name=HDP-UTILS-1.1.0.21-repo-1
> baseurl=http://repo.ambari.apache.org/hdp/centos6/HDP-UTILS-1.1.0.21
> path=/
> enabled=1
> gpgcheck=0
> {code}
> -- "1" is the ID of the repo_version entry in Ambari - so the filename is
> ambari-<stack-name>-<repo-version-id>
> -- Yum Repo ID (HDP-2.5-repo-1) - the repo name used in the file is
> <stack-name>-<stack-version>-repo-<repo-version-id>
> This presents a problem when upgrading a prior version of Ambari. Although
> there is still only 1 record in the {{repo_version}} table, we create a 2nd
> repo file in {{/etc/yum.repos.d}} with an entirely different repository ID
> and name. Because the packages were previously installed with another repo
> identifier, our new code which restricts to the repository associated with
> the command, can't find packages and produces an error.
> - This prevents new components from being added to hosts
> - Client restarts and reinstalls fail
> - Sysprepped Hosts can't be managed
> The {{yum}} command doesn't really allow for us to determine the packages
> installed from other repos nor does it allow the reassignment of installed
> packages from one repo to another.
> Consider the case where Hive is already installed and then the cluster is
> upgraded to Ambari 2.6. When we go to add new hive components, we are
> restricting the packages to that of the current repo ({{HDP\-2.5\-repo\-1}}):
> {code}
> [root@c6401 ~]# yum list available --disablerepo=*
> --enablerepo=HDP-2.5-repo-1 | grep hive2
> hive2.noarch 2.1.0.2.5.0.0-1237.el6
> HDP-2.5-repo-1
> hive2-jdbc.noarch 2.1.0.2.5.0.0-1237.el6
> HDP-2.5-repo-1
> {code}
> Unfortunately, this misses the hive already installed since they are
> associated with another repo ({{@HDP\-2.6.2.0\-193}})
> {code}
> hive2_2_6_2_0_193.noarch 2.1.0.2.6.2.0-193
> @HDP-2.6.2.0-193
> hive2_2_6_2_0_193-jdbc.noarch 2.1.0.2.6.2.0-193
> @HDP-2.6.2.0-193
> {code}
> I think the following needs to be done to fix this situation:
> - If the repo file exists, then do nothing if the file contents match
> - If the repo file does not exist, then scan {{/etc/yum.repos.d}} to see if
> any repos match the URL. If we hit a match, then we need to scan the repo to
> extract the old, original repository ID
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
