I think I misunderstood the intent of this jira. This is not a user facing api, as I originally thought, but rather a refactoring of internal code with respect to how various components access configuration pieces of Solr. If that is the correct understanding, please go ahead as soon as possible without SIP and this is something which is important and needed and voting on this seems unnecessary.
On Wed, 9 Sep, 2020, 1:27 am David Smiley (Jira), <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192425#comment-17192425 > ] > > David Smiley commented on SOLR-14843: > ------------------------------------- > > Yeah a SIP. Lets look at this in a light-weight way... copy-paste to a > Confluence doc, and start a dev list discussion pointing to it, perhaps > with the same text in the email as well. The dev list discussion enhances > visibility about SIP-worthy matters. The SIP part I'm more dubious on is > voting, but it could be very lazy-consensus -- at some point say what you > plan to do and just start doing it unless you get a veto. CC [~janhoy] > > [~ilan] Code/config evolution is a general issue that is not specific to > this proposal. I've seen the first option you list (code2 reads config1) > used most often. It's basically the writer of the code in question to deal > with this, not the platform. It's not clear to me how this proposal would > be modified to handle this concern in the platform itself... and I'm a > little skeptical about wether it should. > > > 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: [email protected] > For additional commands, e-mail: [email protected] > >
