markhoerth opened a new pull request, #12242: URL: https://github.com/apache/gravitino/pull/12242
### What changes were proposed in this pull request? Rewrites `docs/iceberg-rest-engine/trino.md` so it covers the whole Trino catalog file rather than the connection properties alone, and links to `credential-vending.md` for catalog-side setup instead of restating it. Corrections: - `fs.native-s3.enabled` is renamed to `fs.s3.enabled` as of Trino 481, when legacy object storage support was removed. The page documented only the old name. - The native S3 file system floor was listed as Trino 430. It is 419. - The page stated that Trino vends credentials for S3 only, citing trinodb/trino#23238 as an open feature request. Trino 481 closed it and added Azure. - The credential refresh limitation was presented as current. Trino 481 added refreshable vended credentials, so it now applies only to earlier releases. Additions: - A capability-to-release table, since the page spans behavior that requires Trino 419, 458, 481, and 482. - A section on which Gravitino catalogs the IRC serves, covering the dynamic and static config providers, the fact that `gravitino-metalake` names exactly one metalake fixed at server startup while catalogs within it are picked up dynamically, and the three conditions Gravitino access control needs over the IRC. - The credential vending request sequence, and an explicit statement that vended credentials are scoped to the table path rather than to the calling user. - A symptom-to-cause troubleshooting table. - Two known issues: the query JSON credential exposure advisory (GHSA-x27p-5f68-m644) and a version-specific consumption bug (trinodb/trino#27416). - Explanations of how each authentication option works, including where Trino obtains the token and how it presents it, and what `iceberg.rest-catalog.http-headers` actually is. ### Why are the changes needed? A user configuring Trino against the Gravitino IRC could not answer several questions from this page and required a separate document to complete the setup. The page had two structural problems. It documented the Trino side of credential vending while delegating the entire Gravitino side to a link, but most failures in this path originate on the Gravitino side. A reader could write a correct Trino catalog file and still get no vending, with nothing on the page to help them locate the cause. It also listed upstream bug reports under Known Issues but had no troubleshooting section. Someone debugging arrives with a symptom, not an issue number, so the existing content did not match how the page was being used. Separately, the property rename in Trino 481 meant the documented Quick Start would not start on a current Trino release. ### Does this PR introduce any user-facing change? Documentation only. No API or property changes in Gravitino. The page now documents Trino property names that changed upstream: - `fs.s3.enabled` replaces `fs.native-s3.enabled` for Trino 481 and later. Both names are documented, with the release each applies to. - Newly referenced Trino properties: `iceberg.rest-catalog.http-headers`, `iceberg.rest-catalog.case-insensitive-name-matching`, `iceberg.rest-catalog.oauth2.server-uri`. - Newly referenced Gravitino properties: `gravitino.iceberg-rest.catalog-config-provider`, `gravitino.iceberg-rest.gravitino-metalake`, `gravitino.iceberg-rest.default-catalog-name`. ### How was this patch tested? The configurations were exercised against Gravitino 1.3.0 and Trino 478 with AWS S3, twice: once with authorization disabled to isolate vending from identity, and once with OAuth2 against Keycloak and authorization enabled. In both runs Spark wrote the table and Trino read it back using vended STS credentials. Behavior at Trino 481 and later, including the property rename and refreshable vended credentials, comes from Trino's documentation and release notes rather than from that run. The page marks which is which. -- 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]
