[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201668#comment-17201668
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14843:
------------------------------------------------------
I don’t know what Andrzej was thinking when he created this Jira, but what
thought when I saw it was something like:
The “consumer” side (our code, components, etc) could look something like:
{code:java}
int myInt = Config.getInteger(“some.configurable.thing”, default: 30);
String myStr = Config.getString(“some.configurable.string”, default: “foo”);
MyObject myStr = Config.get(“some.configurable.obj”, new SomeSortOfFactory());
{code}
Maybe even be able to support attach an onChange event, like
{code:java}
int myInt = Config.getInteger(“some.configurable.thing”, default: 30, onChange:
(v) -> { setMyInt(v); refresh()});
{code}
or something.
Then, this {{Config}} class could load the configuration from a predictable
hierarchy, something like:
{noformat}
system props > env > cluster props > node props
{noformat}
(don’t know if that’s the right order, and again, there could be more than one
hierarchy), so that a property can be set in the node configuration, but could
be overriden by collection level properties, etc.
One extra nice thing of an approach like this is that we could have an API to
show exactly the current configuration and where each config is coming from,
something like:
{code}
some.configurable.string: {
value: “bar”,
source: “collection property”
}
some.configurable.thing: {
value: 30,
source: “default”
}
{code}
Maybe even a timestamp of the change or something.
> Define strongly-typed cluster configuration API
> -----------------------------------------------
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Andrzej Bialecki
> Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
