Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.0.0
-
None
Description
We copy tarballs to HDFS in several places. The problem is that during Resource Manager Start in RU it copies
/usr/hdp/current/tez-client/lib/tez.tar.gz to hdfs:///hdp/apps/{{ hdp_stack_version }}/tez/
for the hdp_stack_version value that comes from running "hdp-select status hadoop-yarn-resourcemanager".
So the destination is correct (uses the "to" version), but the source is incorrect because the tez-client symlink is still pointing to the older version, since tez-client only switches to the newer version when the Clients are upgraded, which occurs later during the orchestration.
The fix is that during RU, the source location of the tarballs must be /usr/hdp/{{ hdp_version }}/component/tarball.tar.gz
where {{ hdp_version }} is the version going to.
Another problem is that during RU, HiveServer2 Start is not copying mapreduce.tar.gz tarball to HDFS. In this Jira, we should also clean up the tarball source and destination variables to come from a file instead of configs in cluster-env.
Attachments
Attachments
Issue Links
- links to