DanielLeens commented on issue #12766: URL: https://github.com/apache/seatunnel/issues/12766#issuecomment-6168240886
Thanks for the detailed report. I checked the current Hudi connector path: it has a keytab-login helper that establishes the Hadoop UGI from the supplied configuration, and the writer creates the Hudi write client before the failing write operation. The current trace reaches the Hudi writer, but it does not show enough of the worker-side initialization to distinguish a missing Kerberos context from configuration/classloader propagation into the Hudi client. The fact that the same credentials work with HdfsFile and Iceberg is useful evidence, but it is not yet enough to identify the Hudi-specific difference. Could you please add the following, with all credentials and host details removed: 1. The exact SeaTunnel 2.3.13 distribution/build, Hudi connector plugin/JAR version, and deployment mode. 2. The complete exception chain from the first Hudi initialization failure, plus the worker log around keytab login and Hudi write-client creation. 3. The Kerberos-relevant, sanitized settings from `core-site.xml`, `hdfs-site.xml`, and `hive-site.xml`; please do not upload the keytab. 4. Whether those XML files and the keytab are present and readable by the actual worker process user, and whether the failure is cluster-worker-only or also reproduces in local mode. 5. A minimal Hudi-only reproduction if possible, including the Hudi and Hadoop dependency versions visible in the worker process. With that evidence we can trace the UGI/configuration handoff into the Hudi client and determine whether this is a connector bug or an environment-specific authentication setup problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
