A standalone mode should be nothing but a SolrCloud setup with an embedded ZK and a single node.
If users want to edit config files they can still do it . People edit config files all the time in SolrCloud today. Directly editing files on a filesystem cannot be a requirement that keeps as from moving on to a unified model On Fri, Oct 18, 2019 at 4:36 AM Shawn Heisey <[email protected]> wrote: > > 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] > -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
