Ivan Bessonov created IGNITE-25041:
--------------------------------------

             Summary: Support configuration deletion
                 Key: IGNITE-25041
                 URL: https://issues.apache.org/jira/browse/IGNITE-25041
             Project: Ignite
          Issue Type: Improvement
            Reporter: Ivan Bessonov


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)

Reply via email to