GitHub user FANNG1 added a comment to the discussion: [DISCUSS] Long-term architecture for Lance support in Gravitino
One possible simplification is to decide that Gravitino does **not** support non-Gravitino namespace backends for Lance. In that model, the main change from the current direction is: ```text Only support the gravitino backend when Lance REST runs in auxiliary mode. ``` So the architecture keeps: ```text Lance REST -> Gravitino internal dispatcher -> Gravitino Lance catalog metadata ``` And removes these paths from the long-term design: ```text standalone Lance REST -> Gravitino HTTP client namespace-backend = path namespace-backend = rest Lance REST as a generic Lance namespace gateway ``` This makes Lance REST closer to Iceberg REST in Gravitino: it becomes an engine-facing protocol layer for a Gravitino-managed Lance catalog, rather than a router across multiple Lance namespace authorities. The implications are: - `gravitino-uri` is not needed by Lance REST, because the Gravitino backend only works in auxiliary mode. - We do not need a standalone HTTP client path such as `HttpCatalogFetcher` for Gravitino metadata. - Metadata authorization only targets namespace/table objects under the Gravitino Lance catalog. - Credential vending is driven by Gravitino policy, with Lance REST translating the result into Lance `storage_options`. - Existing generic catalog Lance tables can remain as a compatibility path, but the new primary path is still `provider=lance`. This would significantly reduce the design scope and avoid several difficult boundary questions around standalone Gravitino access, path backend authorization, and REST backend credential vending. GitHub link: https://github.com/apache/gravitino/discussions/11295#discussioncomment-17101825 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
