[
https://issues.apache.org/jira/browse/IGNITE-25041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis reassigned IGNITE-25041:
------------------------------------------
Assignee: Philipp Shergalis
> Support configuration deletion
> ------------------------------
>
> Key: IGNITE-25041
> URL: https://issues.apache.org/jira/browse/IGNITE-25041
> Project: Ignite
> Issue Type: Improvement
> Reporter: Ivan Bessonov
> Assignee: Philipp Shergalis
> Priority: Major
> Labels: ignite-3
>
> h3. Problem
> There are instances where a configuration has been introduced to the released
> version of Ignite, that doesn't really need to be there.
> Having an unused configuration value is a bad idea. If we simply delete it
> from the code, we'll fail while parsing the configuration of already existing
> node/cluster after the upgrade.
> h3. Solution
> When we read/receive configuration values from a "configuration storage", we
> should have an additional phase of filtering-out the "junk". How are we going
> to do that:
> * Each {{ConfigurationModule}} should provide a list of configuration
> templates, deemed {_}"deleted"{_}.
> ** Or it could be a hard-coded list in "Gradle configuration module" itself,
> but that would make testing more complicated, so I don't like this idea
> * Each template should look like a following string:
> ** {{ignite.my.deleted.property}} - for regular deleted properties
> ** {{ignite.list.*.deletedProperty}} - for named list elements. Arbitrarily
> nested named lists should be supported
> * Upon encountering a configuration name that fits the description, we
> should ignore it.
> * We should keep in mind, that in general these templates describe prefixes,
> not individual configurations. We might ignore the entire configuration
> sub-tree if that's what we have deleted.
> * When saving the configuration back into the storage, we should
> transparently delete all ignored properties that we have read.
> h3. Testing
> Testing should involve all implementations of configuration storages, and
> multiple classes of configuration schemas that would emulate and "upgrade"
> with the changed schema. In these tests the only difference would be a "part
> of configuration is deleted".
> All combinations of deleted properties should be tested:
> * Individual property
> * Regular sub-tree
> * Sub-tree that contained a named list
> * Individual property somewhere inside of a named list
> * Maybe some nested named lists
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
