[I] Dynamic config DELETE should fall back to the default value, not the server.yaml startup value [fluss]

["MicheleGuerriero (via GitHub)" <gi...@apache.org>]

MicheleGuerriero opened a new issue, #4627:
URL: https://github.com/apache/fluss/issues/4627

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.
   
   ### Motivation
   
   Today, `Admin.alterClusterConfigs()` with `AlterConfigOpType.DELETE` removes a dynamic override, and the server falls back to the value it read from `server.yaml` at startup. Only when the key is absent from `server.yaml` does it fall back to the Fluss default. A startup value cannot be removed through the API at all; only a restart with an edited `server.yaml` removes it.
   
   This is a problem for tooling that owns `server.yaml`, such as a Kubernetes operator that renders the file from a custom resource and pushes dynamic keys through the Admin API. When a user removes a dynamic key from the resource, the tool rewrites `server.yaml` for the next restart, but it has no way to apply the removal to the running servers:
   
   - If the key was only in `server.yaml`, there is no override to delete, and the server keeps the old value.
   - If the key was changed since startup, `DELETE` drops the override, and the server goes back to the old startup value instead of the default.
   
   In both cases the running cluster keeps a value the user removed, and a full rolling restart is the only way to apply a change to a key that is meant to be dynamic.
   
   Example, with `kv.snapshot.interval: 10min` in `server.yaml`:
   
   1. `SET kv.snapshot.interval=20min`: the server uses 20min.
   2. `DELETE kv.snapshot.interval`: the server uses 10min again, not the default.
   
   ### Solution
   
   Make `DELETE` remove the key's effective value entirely, so the server uses the Fluss default whether or not `server.yaml` sets the key. `describeClusterConfigs()` would then list nothing for that key.
   
   If changing `DELETE` itself is a compatibility concern, an explicit opt-in gives the same result, for example a new `AlterConfigOpType` such as `RESET_TO_DEFAULT`, which removes both the override and the startup value of a dynamic key.
   
   ### Anything else?
   
   A related issue appears in 1.0.0. If an override is set to the same value as the startup value and then deleted, the deletion is skipped and the override stays listed as `DYNAMIC_SERVER_CONFIG` (`DynamicServerConfig#processDeletions`, lines 295-298, and the early return in `updateCurrentConfig`, lines 228-234). The change above would remove that case too.
   
   ### Willingness to contribute
   
   - [ ] I'm willing to submit a PR!
   


-- 
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: issues-unsubscribe@fluss.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Dynamic config DELETE should fall back to the default value, not the server.yaml startup value [fluss]

["Jackeyzhe (via GitHub)" <gi...@apache.org>]

Jackeyzhe commented on issue #4627:
URL: https://github.com/apache/fluss/issues/4627#issuecomment-6250903291

   The fallback behavior described here matches the current implementation. `DynamicServerConfig#processDeletions` restores the value from the configuration the server was constructed with, and `DynamicConfigChangeTest#testOverrideConfigs` explicitly tests restoration of the startup value after DELETE. Resetting to the Fluss default would therefore change the existing behavior.
   
   For a config with a default, such as `kv.snapshot.interval`, explicitly SETting that default appears to offer a workaround for the running servers. However, it leaves a dynamic override and requires the tooling to know the default; it does not provide the reset semantics requested here.
   
   The config-source bookkeeping issue appears separate. When there are no effective value changes, `updateCurrentConfig` returns before refreshing `dynamicConfigs`. For example, with startup value A, the sequence SET B → SET A → DELETE appears to leave the key reported as `DYNAMIC_SERVER_CONFIG`, provided no other config change causes the internal state to refresh. A direct SET A immediately after startup can also skip recording the dynamic override in memory. These are code-reading observations, not runtime reproductions, but they suggest that source bookkeeping should be updated even when the effective value does not change.
   
   Could we address the bookkeeping issue independently, while discussing the reset semantics separately? For an explicit reset, should callers be responsible for updating server.yaml, as in the operator scenario here, or should the reset remain effective across restarts even when the file still contains the key?


-- 
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: issues-unsubscribe@fluss.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org