[
https://issues.apache.org/jira/browse/KUDU-3333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489085#comment-17489085
]
David Mollitor commented on KUDU-3333:
--------------------------------------
Hello [[email protected]] . Yes, Sentry was in place when I was hitting
this issue.
Regardless, such diagnostic data would be helpful regardless of the security
apparatus
> 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)
