[ https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192855#comment-17192855 ]
Jan Høydahl commented on SOLR-14843: ------------------------------------ [~dsmiley] Feel free to adapt the SIP page instructinos to fit our needs. It should probably mention that a VOTE is optional but should be held if the dev-list discussion is clearly not conclusive. IMO a [VOTE] thread is light-weight, and a successful VOTE is a good foundation to start a huge work effort from, and likewise a failed VOTE will get you back to the design phase instead of wasting days of effort which ends up in a -1 on a Jira or worse a revert further down the road. > 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