[ 
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192099#comment-17192099
 ] 

Ishan Chattopadhyaya commented on SOLR-14843:
---------------------------------------------

This warrants a SIP, imho.

> 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

Reply via email to