[
https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17684056#comment-17684056
]
Maxim Muzafarov commented on CASSANDRA-15254:
---------------------------------------------
[~dcapwell], [~blerer], [~cnlwsu]
Please, take a look.
h2. Configuration Management
h3. Requirements
Let me first formulate the solution requirements that I have in mind, based on
all the comments above:
* We want to make the SettingsTable virtual table updatable (support the
update statement over it);
* We should restrict the use of delete or insert statements on the
SettingsTable because the available properties are determined by the Config;
* When a configuration property is changed, the current node reaction should
be preserved, regardless of which user interface was used: JMX, vtable or CLI;
* Changing the configuration property must be consistent regardless of which
interface was used;
* The Config class has no getters or setters of its own and delegates its
mutation to other classes, such as DatabaseDescriptor and/or GuardrailsOptions,
we want to preserve the way the configuration is accessed and changed;
* Our aim is to design the solution in such a way that it can be easily
extended and the property can be accessed. We should also consider future
extensions using other node configuration layers like environment variables or
system properties.
* Since the update statement provides a string representation of a property
value, it seems we need to create a bunch of converters for each type that
might be set. I'd like to limit the number of changes in this patch by just
supporting primitive types, enums and some simple datatypes like DurationSpec
and/or DataStorageSpec, leaving collections, maps,
TransparentDataEncryptionOptions etc for other patches.
h3. The solution design
h4. Registry
Since we intend to change configuration properties from different user
interfaces, the main part of the solution design is to create a central
registry of configuration properties to manage access to the properties source
- the Config class. The Registry must provide the following operations:
* Contains by property name;
* Get value by property name;
* Get all property names;
* Update value property by name;
* The subscription on property changes
I've created the ConfigurationRegistry class that implements the Map interface
as the closest one by the set of methods available and its nature so that all
the flat properties of the Config are represented as a collection of data.
However, as the pull request is still a draft to demonstrate the general idea,
I would like to focus on the high-level solution design first and change such
minor details later.
h4. Registry Access
No less important is the way in which configuration fields can be accessed and
managed in this solution by this Registry. There are a few possible options we
could have, each with its pros and cons:
# Use the DatabaseDescriptor/GuardrailsOptions setter/getter methods directly
in auto-generated classes to set a relationship between the property name and
its setter/getter methods;
_Pros:_ The right methods are used to access Config, easy to debug in case of
errors, easy to see setter/getter method usages and classes dependencies, type
safety since the type of property ;
_Cons:_ Require additional utils to generate such classes, the additional
classes themselves increase the size of PR;
# Call the DatabaseDescriptor/GuardrailsOptions setter/getter methods using
reflection; based on the property name, we can look through the
DatabaseDescriptor for corresponding setter/getter methods and call the method
to set the property;
_Pros:_ The right methods are used to access Config, require fewer changes
compared to option 1 to achieve the solution goal, and the setter/getter
methods enforce the expected types for the properties.
_Cons:_ Harder to understand and maintain - you will not see the
setters/getters usages in case of any analysis, it is not safe if someone will
change a setter name that violates the naming contract;
# Set/get a Config's field through the SnakeYaml Property class by using
reflection under the hood;
_Pros:_ Easy to implement with minimal changes;
_Cons:_ harder to understand how the config is being accessed and manipulated,
may violate the contract of config management passing by getter/setter methods,
not easy to debug and cause in case of failure, reflective access to fields can
bypass any validations or restrictions;
I chose option 1 because it provides much more code clarity for users and
developers, which I think is more important than its drawbacks.
h4. Layer dependency
Maybe the diagram below may shed light on the design.
!Configuration Registry Diagram.png|width=640,height=372!
> Allow UPDATE on settings virtual table to change running configurations
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-15254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15254
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
> Reporter: Chris Lohfink
> Assignee: Maxim Muzafarov
> Priority: Normal
> Attachments: Configuration Registry Diagram.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Allow using UPDATE on the system_views.settings virtual table to update
> configs at runtime for the equivalent of the dispersed JMX
> attributes/operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
