[
https://issues.apache.org/jira/browse/KUDU-3333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488270#comment-17488270
]
Abhishek commented on KUDU-3333:
--------------------------------
I've looked into this and appears the reason this could happen could be if kudu
user is not in hive group in HMS nodes and kudu+hms and kudu+sentry integration
is in place already.
[https://github.com/apache/kudu/blob/branch-1.10.x/src/kudu/master/sentry_authz_provider.cc#L348]
> Include Table Counts in kudu hms Dryrun
> ---------------------------------------
>
> Key: KUDU-3333
> URL: https://issues.apache.org/jira/browse/KUDU-3333
> Project: Kudu
> Issue Type: Improvement
> Components: hms
> Reporter: David Mollitor
> Assignee: Abhishek
> Priority: Minor
>
> I have been bitted several times now by a particular scenario.
> Consider a scenario where the user running {{kudu hms fix}} can see the table
> metadata in HMS but cannot see the Kudu tables {{kudu table list}} because of
> some ACL discrepancy between the two services.
> In this case, the kudu tool believes that every record in HMS is orphaned and
> (given --{{drop_orphan_hms_tables}}) drops *all* of the HMS records. It would
> break workloads if this were to happen, until the metadata could be restored.
> When running the {{kudu hms fix ... --dryrun=true}} command, it would be
> really helpful to print (at the bottom of the table) the number of Kudu
> tables and the number of HMS tables that were fetched. In this way, if I see
> that either one of them is zero, I can assume there is an ACL issue.
> Thanks.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
