Details
-
Bug
-
Status: Open
-
Critical
-
Resolution: Unresolved
-
2.4.2
-
None
-
None
Description
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.
Attachments
Issue Links
- is related to
-
AMBARI-18368 Atlas web UI alert after performing stack upgrade to HDP 2.5 and adding Atlas Service
- Resolved