collado-mike commented on code in PR #1068:
URL: https://github.com/apache/polaris/pull/1068#discussion_r1978829961
##########
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:
As a matter of best practice, it is very nearly always a good idea to make
behavior changes behind a config flag. It's very easy to add a config that
allows replicating the exact behavior we see today and then to remove that
config if users are happy with the proposed change. What's not easy to do is to
bring that behavior back to existing deployments once the code is ripped out.
Making small, incremental changes to ensure we understand the unintended side
effects seems pretty uncontroversial to me. I think Yufei's suggestion to keep
the config but mark it deprecated is reasonable and allows us the opportunity
to make changes carefully. Why is that controversial?
--
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]
