Validate configurations for BigLake external catalogs
- Dominant language
- Java
- Stars
- 2.1k
- Forks
- 522
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 137
Description
### Is your feature request related to a problem? Please describe.
## Problem
A misconfigured BigLake Iceberg REST external catalog can currently be created or updated successfully and fail later during federation or credential vending. The resulting errors do not clearly identify the invalid configuration.
## Requirements
Validate BigLake external catalog configuration during catalog creation and update.
The validation applies only when an external Iceberg REST catalog uses GCP authentication and targets the official BigLake endpoint, `https://biglake.googleapis.com/iceberg/v1/restcatalog`.
The validation should provide actionable errors for invalid:
- BigLake endpoint configuration;
- remote catalog or warehouse identifier;
- quota-project header configuration;
- GCS storage locations and service account configuration when credential vending is enabled.
Existing generic GCP-authenticated Iceberg REST catalogs that do not target the BigLake endpoint must retain their existing behavior.
Existing CLI-created BigLake catalogs that store `header.x-goog-user-project` in catalog properties must remain valid. New CLI-created GCP Iceberg REST catalogs must store this header in connection configuration.
The validation must apply only to BigLake configurations and must not change the behavior of other GCP-authenticated Iceberg REST catalogs.
## Expected outcome
Invalid BigLake configurations are rejected early with field-specific validation errors, while valid configurations continue to work for both create and update operations.
### Describe the solution you'd like
_No response_
### Describe alternatives you've considered
_No response_
### Additional context
_No response_
Contributor guide
Research direction
The issue names no files or tests, so start by locating the catalog creation and update entry points for GCP-authenticated Iceberg REST catalogs. Trace existing CLI handling for the quota-project header, then identify validation coverage for BigLake endpoint, identifiers, storage locations, and service accounts. Done means invalid BigLake configurations fail with field-specific errors while other GCP catalogs retain their behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- gcp, java
- Domain
- backend, cloud, databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100