[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192104#comment-17192104
]
Ilan Ginzburg commented on SOLR-14843:
--------------------------------------
I would suggest this new system allows setting default configuration at dev
time or pre deploy time (before ZK is even started) that are reflected in
deployed clusters. Otherwise defaults will live in Java code which is less
convenient to change.
Also would be useful to provide standardized "override using system properties"
as is possible for configuration values defined in {{solr.xml}}.
Finally, cases in which code and configuration need to be deployed atomically
can't be ignored. Old code1 needs config1, new code2 version needs config2. How
do we mange this? Here's a few options (non exhaustive list):
* Updating to code2 while still keeping config1 (assumes code2 knows how to
read and act upon config1) then updating the config to config2 when no more
copies of code1 are running,
* Creating some indirection to have both config1 and config2 present at the
same time, with code1 reading config1 and code2 reading config2,
* Coding such breaking changes (between code1 and code2) as new different code
using totally new config (similar to previous item but implemented by
considering code1 and code2 as totally different rather than two versions of
the same thing).
> 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
