Thanks Shawn It would surely be nice with a spring clean of configs for some future major version. Welcome to start a dev-list thread on that :)
The important for this thread is to decide what solr.xml is and isn’t. I think another key point is whether a config in solr.xml requires a node restart or not. It seems most of them do require a restart, which further implies it to be node-local. If you were to change solr.xml in zk, nothing would happen unless you restart every node after that edit. So you need to touch each node anyway.. Jan Høydahl > 21. sep. 2022 kl. 21:58 skrev Shawn Heisey <[email protected]>: > > On 9/21/22 07:10, Jan Høydahl wrote: >> Since 9.0 Solr can start with an empty SOLR_HOME as it will use defaults in >> their place >> <https://solr.apache.org/guide/solr/9_0/upgrade-notes/major-changes-in-solr-9.html>: >> "Solr no longer requires a solr.xml in $SOLR_HOME. If one is not found, >> Solr will instead use the default one from $SOLR_TIP/server/solr/solr.xml." > > You can see how much I keep up with things, didn't know that was already > handled. I haven't used Solr professionally for a few years now, which means > there is little time during work hours to keep close track of Solr's > progress. Thank you for letting me know. I think that means I can delete > solr.xml from my tiny Solr install. > >> I agree with David's comment on the JIRA that this is also a question about >> what we want solr.xml to be conceptually - a node-config file, or a >> cluster-config file. We have other locations for cluster-wide configuration. >> Today I think solr.xml is a mix of the two. A value like "zkClientTimeout" >> could be cluster-wide while "host" and "hostPort" are of course node-local. > > Topics for different threads below, and I am aware that what I am describing > is a TON of work. I would help with it as much as I can. > > I think the entire configuration system needs a revamp. > > 1) Choose one format for all configs. Currently it is a mix of xml, > properties, and json. I really like the compactness of json, but the > official standard does not support comments, and we use those extensively in > the out-of-box xml configs. Many of the libraries that parse json do have > comment support, but I worry about relying on nonstandard extensions. > Related: For JSON support, let's decide whether we are using jackson or > noggit and remove the other one. I suspect that some of our other > dependencies depend on jackson, which may make the choice for us. Can jackson > be used for the other things we do with XML? I would like to reduce how many > dependencies we have, make the download smaller. > > 2) Make sure the entire config system follows good inheritance rules. > Cluster config takes effect unless node config overrides, and so on. Cluster > config probably only applies to cloud mode, so it should be in ZK, and > completely configurable in the admin UI. Default node config in cloud mode > should probably actually be part of cluster config, and we could even have > node-specific overrides in ZK as well so they are easy to edit centrally. It > would be very cool if there was central editing even for the things that > normally go in /etc/default/solr.in.sh. > > 3) I think the admin UI should have an option to turn on in-UI editing of > collection/core configurations, and that absolutely everything they can do is > available in the UI. Leave that feature off by default as a security > measure, and have a big red security warning on the button that turns it on. > > I imagine a SolrCloud world where EVERYTHING is configurable in the admin UI, > with some of it turned off by default for security, where you can even change > things like heap size and restart multiple Solr nodes all in the central UI. > It would be very nice if the UI even controlled ZK nodes. As part of that, > eliminating standalone mode is probably prudent. > > A truly ambitious idea would be to have a full software suite that includes > creating a VIP so there is automated redundancy of the central UI's IP > address, with rpm and deb repos for easy install. Containers are very in > right now, so create something similar with docker. > > Thanks, > Shawn >
