ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alejandro Fernandez (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMBARI-18409) Fix conf-select when packages bring in other RPMs, fix hacks added by AMBARI-18368
Date Thu, 15 Sep 2016 22:48:20 GMT
Alejandro Fernandez created AMBARI-18409:
--------------------------------------------

             Summary: Fix conf-select when packages bring in other RPMs, fix hacks added by
AMBARI-18368
                 Key: AMBARI-18409
                 URL: https://issues.apache.org/jira/browse/AMBARI-18409
             Project: Ambari
          Issue Type: Bug
          Components: ambari-admin
    Affects Versions: 2.4.2
            Reporter: Alejandro Fernandez
            Assignee: Alejandro Fernandez
            Priority: Critical
             Fix For: 2.5.0


In AMBARI-18368, we added several hacks to make Atlas work.

STR:
* Install Ambari 2.2.2 with HDP 2.4 and Hive but not Atlas
* Upgrade Ambari to 2.4.0.1
* Install HDP 2.5 bits 

The Hive RPM installs /usr/$stack/$version/atlas with some partial packages that contain Hive
hooks, while the Atlas RPM (not yet installed) is responsible for installing the full content.

If the user does not have Atlas currently installed on their stack, then /usr/$stack/current/atlas-clientwill
be a broken symlink, and we should not create the symlink /etc/atlas/conf -> /usr/$stack/current/atlas-client/conf
.

That is what the addendum fix in AMBARI-18368 did. However, it seems that logic should can
be removed entirely since it was only needed for EU from HDP 2.1 to 2.3 in which the /etc/$comp/conf
symlink doesn't exist at all. In my opinion, Package Install should not be responsible for
setting up those symlinks.

If we mistakenly create this symlink, then when the user performs an EU/RU and then adds Atlas
service then the Atlas RPM will not be able to copy its artifacts into /etc/atlas/conf directory
and therefore prevent Ambari from by copying those unmanaged contents into /etc/atlas/conf.backup,
remove /etc/atlas/conf, symlink /etc/atlas/conf -> /usr/hdp/current/atlas-client/conf.

The addendum patch copied the artifacts from /etc/atlas/conf.backup to /etc/atlas/conf with
the no-clobber option.

It seems that a piece of code right above that was already trying to achieve the same thing.

In conf_select.py, revisit all of the #TODO and #HACK comments.
Basically, we should remove any special logic for Atlas.



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

Mime
View raw message