[jira] [Created] (AMBARI-18409) Fix conf-select when packages bring in other RPMs, fix hacks added by AMBARI-18368

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

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)