HwangDongJun opened a new pull request, #12831: URL: https://github.com/apache/gluten/pull/12831
## What changes are proposed in this pull request? Gluten's official/nightly `libvelox.so` is built on a RHEL-family OS (CentOS/Rocky Linux) with statically-linked HTTP client libraries (libcurl/OpenSSL via vcpkg), which bake in a compile-time default TLS CA bundle path (`/etc/pki/tls/certs/ca-bundle.crt`). On a non-RHEL-family runtime image (e.g. Debian/Ubuntu, where the CA bundle instead lives at `/etc/ssl/certs/ca-certificates.crt`), that path does not exist. As a result, the native S3 client's TLS handshake fails silently (`curlCode: 77`), and an internal retry loop makes the query look like an indefinite hang with no JVM-visible exception. See #10670 for the original report and #12711 for further diagnosis. A Dockerfile symlink workaround already exists and requires no source change, but this PR instead makes the CA bundle path configurable at runtime, so no image changes are needed either. Since Velox itself lives in a separate repository (`IBM/velox`, fetched during `get-velox.sh`) rather than in this repository, the fix is carried as a source patch applied to the fetched Velox tree, following the same pattern already used for `modify_arrow.patch`: - `ep/build-velox/src/s3-ssl-ca-override.patch`: adds a new Hive connector config, `hive.s3.ssl.ca-file`, with a matching `S3Config::sslCAFile()` getter. At the single `S3Client` construction point shared by both the read and write paths, it sets `Aws::Client::ClientConfiguration::caFile` — the documented AWS SDK C++ mechanism for overriding the TLS CA bundle, which flows through to libcurl's `CURLOPT_CAINFO` — from `hive.s3.ssl.ca-file` if set, otherwise falling back to the `SSL_CERT_FILE` environment variable (a convention also respected by OpenSSL, curl, Python, Node.js, etc.), before finally falling back to the HTTP client's compiled-in default. There is no behavior change if neither is set. - `ep/build-velox/src/get-velox.sh`: applies the new patch during Velox source preparation. - `cpp/velox/utils/ConfigExtractor.cc`: passes `hive.s3.ssl.ca-file` through from the new `spark.hadoop.fs.s3a.ssl.ca-file` Spark config, so it can be set without relying solely on the `SSL_CERT_FILE` environment variable fallback. - `docs/get-started/VeloxS3.md`: documents the symptom, root cause, and both the image-level symlink workaround and this config-driven fix. Addresses #12711. ## How was this patch tested? Verified on a base image with no CA-bundle symlink applied, running a native Iceberg-on-S3 `GROUP BY` query (single partition, ~27k Parquet files) against S3-compatible object storage: - With neither `hive.s3.ssl.ca-file` nor `SSL_CERT_FILE` set, the query reliably hung for 240+ seconds with no error, reproducing the symptom in #10670 and #12711. - With the identical build, query, and native execution plan (confirmed via `numFallbackNodes == 0`), but the CA bundle path set via `SSL_CERT_FILE`, the same query consistently completed in ~43-44 seconds across repeated runs, returning identical, correct results. No existing tests were affected, since `clientConfig.caFile` is only set when `hive.s3.ssl.ca-file` or `SSL_CERT_FILE` is present; otherwise the compiled-in default path is used exactly as before. ## Was this patch authored or co-authored using generative AI tooling? Generated-by: OpenCode claude-sonnet-5 -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
