Hi Polaris community,
We would like guidance on whether Polaris should support provider-specific configuration validation for external Iceberg REST catalogs, and, if so, what the appropriate extension model should be. Context: - Polaris supports the generic `ICEBERG_REST` connection type. - The initial BigLake implementation added provider-specific validation in the shared `PolarisAdminService` create/update path. - Review feedback on PR #5196 raised concerns about putting provider-specific logic in the main admin workflow, introducing a validator without a shared abstraction, and coupling provider configuration rules to Polaris releases. We have closed that implementation and would like to agree on the design before proposing a replacement. Questions: 1. Is provider-specific configuration validation desirable for generic `ICEBERG_REST` federation? 2. If so, should Polaris first define a shared abstraction or extension model for such validation? 3. What ownership and dispatch boundary would keep the shared admin workflow provider-neutral and avoid running provider-specific logic for every catalog operation? 4. Under what conditions, if any, would a separate connection type be preferable to extending the generic `ICEBERG_REST` flow? Links: - Tracking issue: https://github.com/apache/polaris/issues/5195 - Closed initial PR: https://github.com/apache/polaris/pull/5196 - Architecture feedback: https://github.com/apache/polaris/pull/5196#discussion_r3846267047 Thanks, David
