HonahX commented on code in PR #2696:
URL: https://github.com/apache/polaris/pull/2696#discussion_r2389185404
##########
runtime/service/src/main/java/org/apache/polaris/service/admin/PolarisServiceImpl.java:
##########
@@ -124,6 +125,7 @@ public Response createCatalog(
Catalog catalog = request.getCatalog();
validateStorageConfig(catalog.getStorageConfigInfo());
validateExternalCatalog(catalog);
+ validateCatalogProperties(catalog.getProperties());
Review Comment:
I've revised the error message to contain info that
`ALLOW_SETTING_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS` need to be set to allow
explicitly setting sub-rbac at catalog-level.
> But what's being done here is specific to one setting... creating a second
flag for every flag where we want this level of control seems like a bad
precedent to set.
Yeah, I agree this does not scale up in the long term. But I think at this
time, we probably need to identify more use-cases to make a comprehensive infra
enhancement for this type of utility. How about adding a general flag
```
public static final FeatureConfiguration<List<String>>
CATALOG_CONFIG_OVERRIDE_BLOCKLIST = PolarisConfiguration.<List<String>>builder()
.key("CATALOG_CONFIG_OVERRIDE_BLOCKLIST")
.description("A list of feature configuration keys that are not
allowed to be overridden at the catalog level.\n" +
"Any key included here will always use the realm-level
setting, and attempts to override it per catalog will be rejected.")
.defaultValue(
List.of())
.buildFeatureConfiguration();
```
So that people could register feature keys that they want to block catalog
overrides in the future?
--
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]
