Major Description
I recently saw a case where the Java application spit out this error, failing to connect to the cluster:
Caused by: org.apache.kudu.client.NoLeaderFoundException: Master config (master:7051) has no leader. Exceptions received: org.apache.kudu.client.RecoverableException: connection disconnected at org.apache.kudu.client.ConnectToCluster.incrementCountAndCheckExhausted(ConnectToCluster.java:289) at org.apache.kudu.client.ConnectToCluster.access$100(ConnectToCluster.java:49) at org.apache.kudu.client.ConnectToCluster$ConnectToMasterErrCB.call(ConnectToCluster.java:365) at org.apache.kudu.client.ConnectToCluster$ConnectToMasterErrCB.call(ConnectToCluster.java:354) at com.stumbleupon.async.Deferred.doCall(Deferred.java:1280) at com.stumbleupon.async.Deferred.runCallbacks(Deferred.java:1259) at com.stumbleupon.async.Deferred.handleContinuation(Deferred.java:1315) at com.stumbleupon.async.Deferred.doCall(Deferred.java:1286)
Other clients (i.e. Impala) were able to run similar queries without such errors, so it seemed localized to this one application. This was odd given the error message complains about not having a Master leader, a property of the cluster, not the client.
Inspecting the master logs, it was relatively clear that --trusted_subnets was likely to blame (the server-side warning message that is spit out mentions it by name). It would be nice if this was obvious in the clients as well.