lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Renaming SolrCloud
Date Thu, 17 Oct 2019 17:36:44 GMT
On 10/17/2019 10:58 AM, David Smiley wrote:
> Some ideas:
> * Add a config file editor to Solr.  Not sure if our APIs are sufficient 
> here; don't want to add another security risk.

It would be VERY useful to have this.  It should require explicit admin 
action to enable -- not enabled by default, or it will get tagged as a 
security issue.  And I think it should work in both cloud and standalone.

In a similar way, it would be really nice if there was a way to 
edit/add/delete anything in the ZK database right in the admin UI.  It 
will need a caution note saying that doing so can be dangerous, and 
similar to config editing, should not be enabled by default.

> * Add a config path watcher / uploader script that automatically uploads 
> on changes to the file system at a path.
> * Add a new mode of configSets storage such that each node stores it 
> locally yet also syncs a single zNode ID to trigger the watches.  This 
> might use new "file store" / "package store" implementations for the new 
> plugins management.

If it can be made bulletproof, I'm not opposed.  Maybe some kind of 
mirroring of configsets in ZK and on every node.  By paying attention to 
modification times, automatic synchronization could be accomplished -- 
so when a file is changed in one place, whether that is in a node 
configset directory or in ZK, it gets updated in all other locations. 
My worry with this idea is that it will be difficult to avoid the 
implementation being brittle ... but if it's very carefully done, that 
shouldn't be a problem in practice.

I wonder whether deletions could be handled.  Probably need the ability 
to designate one location as the canonical resource if we want that to work.

> These might even avoid the additional collection "reload" step.

I don't know that I like the idea of automated collection reloads, at 
least by default.  Somebody might want to edit a configset for an 
upcoming change, but wait two hours before reloading linked collections 
and activating the change.  Having an option to enable automatic reloads 
if the admin chooses sounds good.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message