flyrain commented on code in PR #1068:
URL: https://github.com/apache/polaris/pull/1068#discussion_r1976064769
##########
polaris-core/src/main/java/org/apache/polaris/core/PolarisConfiguration.java:
##########
@@ -264,4 +264,11 @@ public static <T> Builder<T> builder() {
+ STORAGE_CREDENTIAL_DURATION_SECONDS.key)
.defaultValue(30 * 60) // 30 minutes
.build();
+
+ public static final PolarisConfiguration<Integer>
STORAGE_CONFIGURATION_MAX_LOCATIONS =
+ PolarisConfiguration.<Integer>builder()
+ .key("STORAGE_CONFIGURATION_MAX_LOCATIONS")
+ .description("How many locations can be associated with a storage
configuration")
+ .defaultValue(20)
Review Comment:
We still need to go through the deprecation process even there is no one use
them. Even worse that for an OSS project, we don't know if there are people
using them.
I want to reiterate that, the chance of having a unbounded number of table
locations is quite small. The migration use case is the only one, which
involves manual work anyways. If the policy did exceed the limit, we might just
need provide a clear error message saying "credential vending failed due to the
policy text is too long, please consider remove allowed locations". It should
be fine for users, as they are manually working on the migration use case
anyways.
--
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]
