**case 1：**基于HDP集群二次开发的集群中，在Client执行spark 任务的时候，在客户端页面提示Connecting to ResourceManager at 0.0.0.0:8032异常。如下图所示：
**case 2：**在Client解决上述问题的同时，回归到web页面，进行冒烟测试，在使用Azkaban进行任务调度的时候，该异常二次发生，咦，刚刚已经解决了，为何还会发生呢？此时，心情是崩溃的。
产生原因**case 1：**因为Client会去找Cluster要集群资源，而Client和Cluster要通信，就要能够在及裙房为内互相识别。但现在Client提交的spark任务默认寻找的本机，无法向集群提交，hostname无法被Cluster识别。所以，产生原因主要是Client的hostname被设置成了localhost.localdomain。换句话说，就是hostname没有改。
**case 2：**上述case1解决后，如果项目中azkaban不能正常提交，需要详细查看azkaban的日志。可以在sh脚本中加入如下信息打印：
env或者echo env |grep HOSTNAME，输出azkaban的hostname看一下。这个时候，可能就会是未更改的hostnamelocalhost.localdomain。
为什么会是这个hostname呢？
因为在刚刚修改Client的hostname时，azkaban已经启动了，它启动时读取的hostname是修改之前的hostname。
因此，这个时候，只需要重启azkaban或者修改azkaban的executors表的host属性即可。
解决方案**case 1：**修改hostname，使用命令：hostnamectl set-hostname sais156
如果改完hostname后，spark任务可以运行，就OK。如果还不能运行，需要修改/usr/hdp/2.5.0.0-1245/hadoop-yarn/etc/hadoop路径下的yarn-site.xml文件中的yarn.resourcemanager.address属性，默认是8050，修改成8032即可，如下图。
到此，Spark任务就可以在Client端正常提交给yarn运行了。
**case 2：**解决方法有2种，其一，重启azkaban。其二，修改原数据表executors中的host的值。host的值由之前的localhost.localadmin改为修改后的hostname。
