On Fri, Sep 4, 2020 at 11:24 AM Alexandre Rafalovitch <arafa...@gmail.com> wrote:
> > I really wish the default cores dir was not solr.home itself but one > directory beneath. > Why? That is worth exploring. > Because core discovery looks for cores in directories that are not cores (e.g. filestore) > > I am ok - if others are - with solr.home containing > *) solr.in.sh > *) configset > *) logs > *) log and related configuration > *) userfiles > *) filestore > *) solr.xml > *) actual cores > > However, this feels to me like it makes the cores crowded and - > potentially - interferes/slows-down the recursive core discovery > mechanism. A lot of directories to stat potentially. > Hence add a "cores" dir :-) This is already supported, see "coreRootDirectory" in solr.xml documented here: https://lucene.apache.org/solr/guide/8_6/format-of-solr-xml.html#format-of-solr-xml > But moving cores from under solr.home is a LOT of updates I suspect in > Solr, documentation and 3rd party solutions. I think it's worth it; we should have done this a long time ago. > To me, I would formally > establish a 'node' directory above solrhome and move everything but > solr.xml and cores up there. Including the recently added 'userfiles' > and 'filestore' if at all possible. > Essentially, you are proposing that solr.home *be* the core directory _only_, and that some other dir where all the other stuff currently in solr.home get some new special name. I don't think we need new special dirs though. And I think it's useful that "solr.home" retain all the stuff in it already. Any thoughts on this thread Jan? I mention you because you tend to comment on such matters. > > Regards, > Alex. > > > On Fri, 4 Sep 2020 at 11:04, David Smiley <dsmi...@apache.org> wrote: > > > > On Fri, Sep 4, 2020 at 10:42 AM Alexandre Rafalovitch < > arafa...@gmail.com> wrote: > >> > >> I feel that maybe we don't treat it special mentally, but then it > >> actually is. At least with minimum custom locations configured. > >> > >> Consider: > >> 1) What is in "server", above "server/solr" > >> * resources/log4j2.xml (because of magic jetty classpath mechanism) > >> * logs > >> * NOT server/solr/configsets (but probably should be to avoid > >> confusion with recursive core searching algorithm or just people > >> trying to understand what those directories are) > > > > > > Correct; configsets is in solr.home > > > >> > >> 2) What is in "example/schemaless" > >> * logs (because of hardcoded magic in bin/solr) > >> * NOT log4j2.xml, because we simplified it but also lost an ability to > customize > >> > >> 3) What is in "example/cloud/node1" > >> * logs (same magic) > >> > >> From other discussions, if you try to reproduce examples outside of > >> the example directory, they will log to the global log directory and > >> mess with each other, unless you pass on an individual log directory > >> location for each bin/solr command. > >> > >> > >> I am wondering if the example above solr.home should be the place we > >> try to check for: > >> 1) logging configuration (or override that latest log4 seems to support) > >> 2) logs > >> 3) configsets available to that node > >> > >> 4) maybe solr.in.sh > > > > > > Starting more than one Solr node on a machine is rather unusual, but it > shows up in certain examples, and on a local dev machine, but I don't think > "the real world" (prod). I think it would help a bit if logs were under > solr.home. It's rare to touch logging config, but it'd be interesting to > allow a log4j2.xml in solr.home to take precedence. configsets dir is > already in solr.home. Again, it'd be interesting for a solr.in.sh in > solr.home to take precedence if it is defined. All this would help make a > solr.home a complete place for a Solr node if you want to isolate it from > other nodes -- be it for "example"/tutorial reasons, or for keeping > multiple side-projects together. In addition to all this, I really wish > the default cores dir was not solr.home itself but one directory beneath. > > > >> > >> This would certainly make example setups easy and less magical. > > > > > > Yes; that'd be nice. > > > >> > >> I don't know if this is the right answer. I specifically don't know if > >> this will mess up cloud setups. > > > > > > SolrCloud isn't special with regards to this discussion (I think). > > > >> > >> But I see a pattern that is > >> unacknowledged and think that maybe acknowledging would allow us to > >> have a more general solution that magic in bin/solr. And maybe just in > >> time for the Solr in Docker final decisions. > > > > > > Yeah; I hope you like my suggestions above. > > > >> > >> Regards, > >> Alex. > >> P.s. To make it more interesting, I am also confused about pid files > >> going into bin directory. I bet docker image puts them somewhere else. > >> > >> On Fri, 4 Sep 2020 at 01:04, David Smiley <dsmi...@apache.org> wrote: > >> > > >> > The parent directory of Solr home is not special. Where Solr Home is > (as you know) configurable. It's default location is different too, since > it's in /var/solr for both the Docker & service install script. > >> > > >> > ~ David Smiley > >> > Apache Lucene/Solr Search Developer > >> > http://www.linkedin.com/in/davidwsmiley > >> > > >> > > >> > On Tue, Aug 25, 2020 at 8:31 PM Alexandre Rafalovitch < > arafa...@gmail.com> wrote: > >> >> > >> >> Hello, > >> >> > >> >> What do we call the directory above the solr.home? > >> >> E.g. > >> >> - "schemaless" in example/schemaless/solr/gettingstarted > >> >> - "node1" in > example/cloud/node1/solr/gettingstarted_shard1_replica_n2 > >> >> - "solr" in server/solr/book/conf > >> >> > >> >> In solr.in.cmd we "may be" calling it "solr start dir" > >> >> In bin/solr, we call it SOLR_SERVER_DIR > >> >> In install_solr-service.sh, we sort-of call it SOLR_VAR_DIR > "Directory > >> >> for live/writable Solr files", which is not quite the same because > >> >> apparently pid files go there, while for distribution they seem to go > >> >> into bin > >> >> > >> >> I guess it mostly matters when you have multiple Solr instances > >> >> running on the same machine and you need to separate log locations, > >> >> etc. > >> >> > >> >> Regards, > >> >> Alex. > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
