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.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
