Yes that is true, and I did note as much. If you are writing an EL function in Java, you can also rely on the StandbyException when connecting to explicit hostnames, to detect the active (i.e. one that does not return the exception). This is the way the Java client discovers the active NN. The CM API method can work if you query the role instances directly: http://cloudera.github.io/cm_api/apidocs/v9/path__clusters_-clusterName-_services_-serviceName-_roles_-roleName-.html#GET. The returned apiRole object, on applicable roles such as NameNode or ResourceManager, has a flag for "haStatus" (HA status) as described at http://cloudera.github.io/cm_api/apidocs/v9/ns0_apiRole.html (and http://cloudera.github.io/cm_api/apidocs/v9/ns0_haStatus.html) ... View more

You can use a script such as below to grab active/standby states: # Grab the IDs from the nameservice key NNS=$(hdfs getconf -confKey dfs.ha.namenodes.nameservice1) # Convert to a proper bash array, delimiting on comma NNSA=(${NNS/,/ }) # Lookup state for both STATEA=$(sudo -u hdfs hdfs haadmin -getServiceState ${NNSA[0]}) STATEB=$(sudo -u hdfs hdfs haadmin -getServiceState ${NNSA[1]}) # Test for active state if [ "$STATEA" == "active" ] then ANN=${NNSA[0]} else ANN=${NNSA[1]} fi # Print the host and port of NN that is active ANNHOSTPORT=$(hdfs getconf -confKey dfs.namenode.rpc-address.nameservice1.$ANN) echo $ANNHOSTPORT This (haadmin commands) may however require admin privileges, i.e. the 'hdfs' user or a member of the configured supergroup, to run.   Are you running some non-Java based WebHDFS REST queries that require knowledge of the active NameNode? Just looking to understand why knowing the active seems necessary for your operation. ... View more

> So, to generalize, the mechanism level subcodes can always be taken as some failure in communicating with KDC, right? Yes, it can be always taken as something wrong in the Kerberos layer (not necessarily only KDC, could also be things such as bad enctypes in keytab, etc., but always Kerberos mechanism related) > I also see that despite this error, ZK does continue to function ... so is this error to be really treated seriously? Did a retry of the auth perhaps succeed? Its not normal for it to repeat the errors. ... View more

The HTTPFS port is 14000 (it serves a WebHDFS protocol also) but the regular non-gateway style WebHDFS serves from the NameNode's port of 50070 (or 50075 on a DN). Could you try the below two variants? 1. curl -i "http://quickstart.cloudera:50070/webhdfs/v1/user/user.name=cloudera&op=GETFILESTATUS" 2. curl -i "http://localhost:14000/webhdfs/v1/user/user.name=cloudera&op=GETFILESTATUS" Does either of these work? If not, please re-run with curl -v and post the output here. ... View more

Could you share a sample request URL and output received? It seems to work OK for me, for ex. for my WF ID of "0000000-151116211358117-oozie-oozi-W": ~> curl -L 'http://localhost:11000/oozie/v2/job/0000000-151116211358117-oozie-oozi-W' > wf.json ~> python >>> import json >>> a = json.loads(open('wf.json').read()) >>> len(a['actions']) 2 >>> a['actions'][1]['name'] u'Shell' FWIW, Hue today uses the same API for its Oozie app dashboards, and it does fetch all actions properly too. How old is the targeted WF, and are you able to see the list of actions OK in the web UIs? ... View more