You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Jan Høydahl (Jira)" <ji...@apache.org> on 2022/02/10 10:56:00 UTC
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[ https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490118#comment-17490118 ]
Jan Høydahl commented on SOLR-14843:
------------------------------------
This Jira is tagged as 9.0.
Is this all still on SIP discussion level or has there been any code commits that should be tracked for 9.0?
> Define strongly-typed cluster configuration API
> -----------------------------------------------
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Reporter: Andrzej Bialecki
> Priority: Major
> Labels: clean-api
> Fix For: 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.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org