ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hari Sekhon (JIRA)" <>
Subject [jira] [Created] (AMBARI-10821) Ambari stack upgrade HDP => does not update /usr/hdp/current to correct stack version for unmanaged/unused components
Date Wed, 29 Apr 2015 09:17:07 GMT
Hari Sekhon created AMBARI-10821:

             Summary: Ambari stack upgrade HDP => does not update /usr/hdp/current
to correct stack version for unmanaged/unused components
                 Key: AMBARI-10821
             Project: Ambari
          Issue Type: Bug
          Components: ambari-server
    Affects Versions: 2.0.0
         Environment: HDP => HDP
            Reporter: Hari Sekhon
            Priority: Trivial

After upgrading the HDP stack from => HDP many of the /usr/hdp/current
symlinks are not updated to the new stack version.

On further investigation it appears that services that are not deployed on given nodes are
not updated to the new stack. This could cause some unexpected results where people are running
client code from the wrong version assuming that hdp current should point to the currently
deployed stack or when manually starting services that Ambari is not managing such as hadoop-hdfs-nfs3
(which we are using for example). What's strange is that some components that are not managed
were upgraded to the correct stack version such as spark-client, which I'm not about to move
in to being managed and yet it's hdp current link was upgraded (perhaps because it didn't
exist before).

Below is a unique list of link mappings across all nodes colated to show the divergence of
different nodes:
{code}accumulo-gc -> /usr/hdp/
accumulo-master -> /usr/hdp/
accumulo-monitor -> /usr/hdp/
accumulo-tablet -> /usr/hdp/
accumulo-tracer -> /usr/hdp/
falcon-client -> /usr/hdp/
falcon-server -> /usr/hdp/
flume-server -> /usr/hdp/
hadoop-client -> /usr/hdp/
hadoop-hdfs-client -> /usr/hdp/
hadoop-hdfs-datanode -> /usr/hdp/
hadoop-hdfs-journalnode -> /usr/hdp/
hadoop-hdfs-journalnode -> /usr/hdp/
hadoop-hdfs-namenode -> /usr/hdp/
hadoop-hdfs-namenode -> /usr/hdp/
hadoop-hdfs-nfs3 -> /usr/hdp/
hadoop-hdfs-portmap -> /usr/hdp/
hadoop-hdfs-secondarynamenode -> /usr/hdp/
hadoop-httpfs -> /usr/hdp/
hadoop-mapreduce-client -> /usr/hdp/
hadoop-mapreduce-historyserver -> /usr/hdp/
hadoop-mapreduce-historyserver -> /usr/hdp/
hadoop-yarn-client -> /usr/hdp/
hadoop-yarn-nodemanager -> /usr/hdp/
hadoop-yarn-resourcemanager -> /usr/hdp/
hadoop-yarn-resourcemanager -> /usr/hdp/
hadoop-yarn-timelineserver -> /usr/hdp/
hbase-client -> /usr/hdp/
hbase-master -> /usr/hdp/
hbase-regionserver -> /usr/hdp/
hive-client -> /usr/hdp/
hive-metastore -> /usr/hdp/
hive-metastore -> /usr/hdp/
hive-server2 -> /usr/hdp/
hive-server2 -> /usr/hdp/
hive-webhcat -> /usr/hdp/
hive-webhcat -> /usr/hdp/
kafka-broker -> /usr/hdp/
kafka-broker -> /usr/hdp/
knox-server -> /usr/hdp/
mahout-client -> /usr/hdp/
oozie-client -> /usr/hdp/
oozie-server -> /usr/hdp/
oozie-server -> /usr/hdp/
phoenix-client -> /usr/hdp/
pig-client -> /usr/hdp/
ranger-admin -> /usr/hdp/
ranger-usersync -> /usr/hdp/
slider-client -> /usr/hdp/
spark-client -> /usr/hdp/
sqoop-client -> /usr/hdp/
sqoop-server -> /usr/hdp/
storm-client -> /usr/hdp/
storm-nimbus -> /usr/hdp/
storm-slider-client -> /usr/hdp/
storm-supervisor -> /usr/hdp/
tez-client -> /usr/hdp/
zookeeper-client -> /usr/hdp/
zookeeper-server -> /usr/hdp/
zookeeper-server -> /usr/hdp/{code}
The fix is trivial to hdp-select yourself for each one but it would be nice if Ambari kept
everything cleanly on the right version to avoid surprises like this.

Hari Sekhon

This message was sent by Atlassian JIRA

View raw message