[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192618#comment-17192618
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14843:
------------------------------------------------------
Thanks for starting this work Andrzej, I was thinking about this same thing the
other day. I think Solr developers and users will both benefit from having a
consistent way to get and set configuration.
bq. Using a single hierarchical (or at least key-based) facade for accessing
any global config.
You are thinking in something like "cluster configuration > node configuration
> code defaults..." or something like that? I think that makes sense. The one
tricky part is that sometimes hierarchy may need fo follow a physical path
(cluster config -> node config -> default) and sometimes a logical path
(cluster config -> collection properties -> configset). Unless you are talking
about a completely different thing.
bq. 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.
+1. I think it's important to be able to configure the cluster before starting
the cluster.
bq. Ilan Ginzburg Code/config evolution is a general issue that is not specific
to this proposal. I
I think what Ilan is talking about is similar to what I mentioned in the config
discussion in the dev list (please correct me if I'm wrong, Ilan)? If a new
version of a component that needs to be deployed requires a new set of
configurations, it's easier if those configurations can be deployed together
with the code (in the dev list discussion, this is one of my points in favor of
a node configuration)
> 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
