PHOENIX-5904 Add log if the configed kerberos principal login failed

[infraio]

No description provided.

[joshelser]

Reading what you put in the Jira description, are we gaining anything by letting this fall through when hbase security is on but Hadoop security isn't? We can't properly use HBase authentication if Hadoop authentication is off, can we?

Just thinking that we could fail when hadoop.security.authentication=simple and hbase.security.authentication=kerberos.

[infraio]

I meet this problem when only configured hbase.security.authentication=kerberos. The log shows "Login successful.", but not. The user is not the configured kerberos user.

[stoty]

I also think that it'd be best to explicitly check both kerberos properties, log an error when they are inconsistent, and only attempt the kerberos login if both are set to kerberos.

I also think that we should mimic whatever HBase does when it encounters these inconsistent settings. If it works in unsecure mode, we should do that as well. If it doesn't work, we should just exit with an error.

If the extra check that you've added still fails, fails then we'd better log an error, and exit early.

[infraio]

I also think that we should mimic whatever HBase does when it encounters these inconsistent settings.

If hbase client misconfigured this, it just works without the kerberos. But because the target hbase cluster is in secure mode, so access will fail.

[infraio]

Just thinking that we could fail when hadoop.security.authentication=simple and hbase.security.authentication=kerberos.

I thought we don't need to check the inconsistent config. Just check the current user whether has kerberos credential is enough.

[stoty]

I thought we don't need to check the inconsistent config. Just check the current user whether has kerberos credential is enough.

When the HBase/Hadoop setup is correct, PQS already works fine. You have found a case when PQS behaves in a hard to debug way when the settings are inconsistent.
IMO if we want to make it easier for people to spot these kinds of configuration errors, then the most useful thing to do is to check explicitly for this case, and exit early when we know that the setup has no chance of working.

I assume that if we had such a check, it would have saved you a lot of debugging when you encountered the original issue.

[stoty]

Also, please try to add additional commits when changing the PR, instead of force pushing the new one, unless you are rebasing it.
We have no way of seeing what changes you've made to the PR if you always use force push.

[infraio]

Also, please try to add additional commits when changing the PR, instead of force pushing the new one, unless you are rebasing it.
We have no way of seeing what changes you've made to the PR if you always use force push.

ok

[infraio]

I thought we don't need to check the inconsistent config. Just check the current user whether has kerberos credential is enough.

When the HBase/Hadoop setup is correct, PQS already works fine. You have found a case when PQS behaves in a hard to debug way when the settings are inconsistent.
IMO if we want to make it easier for people to spot these kinds of configuration errors, then the most useful thing to do is to check explicitly for this case, and exit early when we know that the setup has no chance of working.

I assume that if we had such a check, it would have saved you a lot of debugging when you encountered the original issue.

So your advise is? Add a check and exit if inconsistent?

[stoty]

Yes, I think that's the most user-friendly thing to do.

[stoty]

Committed with a minor refactor to improve readability.

[joshelser]

That's great! Thanks Guanghao for your fix! (and Istvan for shepherding in :D)