Marton Greber has posted comments on this change. ( http://gerrit.cloudera.org:8080/24654 )
Change subject: [spark] Add delegation-token support for the Spark connector ...................................................................... Patch Set 3: (3 comments) Two observations otherwise looks good to me. Thanks for working on this! http://gerrit.cloudera.org:8080/#/c/24654/3/java/kudu-spark/src/main/scala/org/apache/kudu/spark/kudu/KuduContext.scala File java/kudu-spark/src/main/scala/org/apache/kudu/spark/kudu/KuduContext.scala: http://gerrit.cloudera.org:8080/#/c/24654/3/java/kudu-spark/src/main/scala/org/apache/kudu/spark/kudu/KuduContext.scala@170 PS3, Line 170: // Note: use a match rather than getOrElse. getOrElse takes a by-name argument Nice! http://gerrit.cloudera.org:8080/#/c/24654/3/java/kudu-spark/src/test/scala/org/apache/kudu/spark/kudu/KuduDelegationTokenProviderTest.scala File java/kudu-spark/src/test/scala/org/apache/kudu/spark/kudu/KuduDelegationTokenProviderTest.scala: http://gerrit.cloudera.org:8080/#/c/24654/3/java/kudu-spark/src/test/scala/org/apache/kudu/spark/kudu/KuduDelegationTokenProviderTest.scala@65 PS3, Line 65: def testDelegationTokensNotRequiredWhenSecurityDisabled(): Unit = { nit: obtainDelegationTokens uses sparkConf.get(KuduMasterConf) (throws NoSuchElementException if absent) rather than sparkConf.getOption(...). This is safe because Spark only calls obtainDelegationTokens when delegationTokensRequired returns true, and that checks the option exists -- but it relies on the Spark framework honoring that contract. A getOption with a descriptive error might be slightly more defensive, though I don't feel strongly. http://gerrit.cloudera.org:8080/#/c/24654/3/java/kudu-spark/src/test/scala/org/apache/kudu/spark/kudu/KuduDelegationTokenProviderTest.scala@84 PS3, Line 84: UserGroupInformation.getCurrentUser.addCredentials(creds) q: This test adds credentials to UserGroupInformation.getCurrentUser but the @After only calls UserGroupInformation.setConfiguration(new Configuration()). Depending on the Hadoop version and JVM forking settings, the credentials may persist in the current user's UGI after the reset -- if KuduContextTest.testFallsBackToExportWhenUgiEmpty runs later in the same JVM, its assertion that getCredentialsFromUGI.isEmpty could fail. Is the test runner configured to fork a new JVM per test class, or should there be an explicit cleanup? -- To view, visit http://gerrit.cloudera.org:8080/24654 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Iacda7b30fd1de3b91301774147bfa8706cefc17f Gerrit-Change-Number: 24654 Gerrit-PatchSet: 3 Gerrit-Owner: Zoltan Chovan <[email protected]> Gerrit-Reviewer: Abhishek Chennaka <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Ashwani Raina <[email protected]> Gerrit-Reviewer: Attila Bukor <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Marton Greber <[email protected]> Gerrit-Reviewer: Zoltan Chovan <[email protected]> Gerrit-Reviewer: Zoltan Martonka <[email protected]> Gerrit-Comment-Date: Thu, 06 Aug 2026 13:52:28 +0000 Gerrit-HasComments: Yes
