[jira] [Commented] (IMPALA-9990) Kudu table ownership

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMPALA-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219791#comment-17219791 ] 

ASF subversion and git services commented on IMPALA-9990:
---------------------------------------------------------

Commit eda06f41ce004cfc7a35d7d26d93e76d54c7cdb0 in impala's branch refs/heads/master from Fang-Yu Rao
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=eda06f4 ]

IMPALA-9990: Support SET OWNER for Kudu tables

KUDU-3090 adds the support for table ownership and exposes the API's of
setting owner on creating and altering tables, which allows Impala to
also pass to Kudu the new owner of the Kudu table for the ALTER TABLE
SET OWNER statement.

Specifically, based on the API of AlterTableOptions#setOwner(), this
patch stores the ownership information of the Kudu table in the
corresponding instance of AlterTableOptions, which will then be passed
to Kudu via a KuduClient.

Testing:
- Added a FE test in AnalyzeKuduDDLTest.java to verify the statement
  could be correctly analyzed.
- Added an E2E test in kudu_alter.test to verify the statement could be
  correctly executed when the integration between Kudu and HMS is not
  enabled.
- Added an E2E test in kudu_hms_alter.test and verified that the
  statement could be correctly executed when the integration between
  Kudu and HMS is enabled after manually re-enabling
  TestKuduHMSIntegration::test_kudu_alter_table(). Note that this was
  not possible before IMPALA-10092 was resolved due to a bug in the
  class of CustomClusterTestSuite. In addition, we may need to delete
  the Kudu table 'simple' via a Kudu-Python client if the E2E test
  complains that the Kudu table already exists, which may be related to
  IMPALA-8751.
- Manually verified that the views of Kudu server and HMS are consistent
  for a synchronized Kudu table after the ALTER TABLE SET OWNER
  statement even though the Kudu table was once an external and
  non-synchronized table, meaning that the owner from Kudu's perspective
  could be different than that from HMS' perspective. Such a discrepancy
  could be created if we execute the ALTER TABLE SET OWNER statement for
  an external Kudu table with the property of 'external.table.purge'
  being false. The test is performed manually because currently the
  Kudu-Python client adopted in Impala's E2E tests is not up to date so
  that the field of 'owner' cannot be accessed in the E2E tests. On the
  other hand, to verify the owner of a Kudu table from Kudu's
  perspective, we used the latest Kudu-Python client as provided at
  github.com/apache/kudu/tree/master/examples/python/basic-python-example.
- Verified that the patch could pass the exhaustive tests in the DEBUG
  mode.

Change-Id: I29d641efc8db314964bc5ee9828a86d4a44ae95c
Reviewed-on: http://gerrit.cloudera.org:8080/16273
Reviewed-by: Vihang Karajgaonkar <vi...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>


> Kudu table ownership
> --------------------
>
>                 Key: IMPALA-9990
>                 URL: https://issues.apache.org/jira/browse/IMPALA-9990
>             Project: IMPALA
>          Issue Type: New Feature
>            Reporter: Attila Bukor
>            Assignee: Fang-Yu Rao
>            Priority: Major
>
> KUDU-3090 adds support for table ownership and exposes setting owner on creating and altering tables. ALTER TABLE <table> SET OWNER USER <user> should now be supported on Kudu tables using the new API and Impala should also set the owner to the real user creating the table on table creation (by default it's the logged in user which in this case would be impala).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org