[IGNITE-15047] Support internal/private properties in configuration framework

• Type: Task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.0.0-alpha3
• Labels: iep-55 ignite-3
• Epic Link: Configuration
• Assignee: Kirill Tkalenko
• Reporter: Ivan Bessonov
• Reviewer: Ivan Bessonov
• Created: 01/Jul/21 15:34
• Updated: 01/Sep/21 13:45
• Resolved: 01/Sep/21 13:45

Description

In order to provide consistent update of configuration and metastorage metadata  we should have configuration values that are hidden form the user.

Requirements are:

• these configuration values should be available from internal code only
• they should not be accessible in JSON or any other configuration view representation
• they can't be updated via CLI's HOCON update requests or any other public API calls

One possible solution is to have configuration schema extensions, registered in "internal" modules - they'll lead to generation of extended VIEW and CHANGE interfaces. All extra fields from these schemas will be marked as internal by configuration framework, technically it is possible.

API notes

I think it would be convenient to have explicit internal configuration extensions like these:

@InternalConfigurationExtension
public class ExtendedConfigurationSchema extends PublicConfigurationSchema {
    // fields
}

 There has to be some "extension descriptor", like a "RootKey", that should be passed into configuration manager constructor (or registered in it by some other means before component's start). It should have at least the information about the schema that it extends.

Following restriction has to be applied:

• There cannot be multiple extensions for the same schema. It is possible to avoid this restriction but it would lead to unnecessary complications (like in polymorphic schemas, that would probably complicate such approach even more: IGNITE-14645).

There's also no point in having extension in the same module. Maybe we should validate this fact.

Every FooConfiguration object must in fact be an instance of InternalFooConfiguration as well. Same applies to *View and *Change interfaces. There's no way that it's possible to design API where its user won't have to perform explicit type casts, so this solution looks fine.

Implementation notes

First of all, annotation processor will be expanded. I suppose that @InternalConfigurationExtension will be the only addition to public configuration-api module, everything else will be hidden in implementation packages.

Traversal / construction API will be expanded as well. I guess that adding a internal flag to a bunch of method will be enough. Having two sets of methods for all and public would just be too much.

After these methods are changed, ConfigurationAsmGenerator and a lot of their usages will have to be fixed. I suspect that most changes will be here and in tests.

Issue Links

• links to: GitHub Pull Request #290