[ https://issues.apache.org/jira/browse/SOLR-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16711533#comment-16711533 ]
Amrit Sarkar edited comment on SOLR-13035 at 12/14/18 4:03 PM: --------------------------------------------------------------- Thanks [~janhoy] for the feedback; bq. Looks scary to do SOLR_LOGS_DIR="$(pwd)/$SOLR_LOGS_DIR". It would be better to require the user to configure absolute path here. Sure. I felt supporting relative path makes it a bit easy for deploying multiple Solr nodes on the machine/server. If {{$(pwd)/$SOLR_LOGS_DIR}} is not the right way to do; probably {{SOLR_TIP/$SOLR_LOGS_DIR}}. The absolute path is supported as the original design. bq. In general, I'd prefer of much of the logic regarding folder resolution etc was done in the common SolrCLI.java so as little logic as possible needs to be duplicated in bin/solr and bin/solr.cmd Yeah makes sense. I followed the same resolution criteria implemented for SOLR_HOME, will move that logic to SolrCLI.java. bq. While I believe solr.xml could be created if not exist, I'm not so sure we should go create SOLR_DATA_HOME if it does not exist? Sure. Creating SOLR_DATA_HOME if not exist was again minor improvement for end-user, just like $SOLR_LOGS_DIR, though not necessary. bq. I agree on the goal of making Solr more container friendly and clearly separate what paths can be made R/O and what paths typically need a separate volume mounted. Can you perhaps create a diagram that clearly shows the various directory paths we have today with their defaults and how they will be changed? We intend not to change the default respective directory paths but instead makes it easy to run in a container environment. SOLR_TIP -> solr installation directory Default state: {code} WRITE specific dirs from Solr/Zk node. SOLR_TIP -----> server ------> solr ------> [data_dir] Index files SOLR_TIP -----> server ------> solr ------> [instance_dir] Core properties SOLR_TIP -----> server ------> solr ------> [zoo_data] Embedded ZK data SOLR_TIP -----> server ------> [logs] READ specific contents in the same directory [server/solr] SOLR_TIP -----> server ------> solr ------> solr.xml [changes requires NODE restart] SOLR_TIP -----> server ------> solr ------> [configsets] Default config sets {code} For the below-stated startup command with the current patch; R/W directories will look like following; {code} cd $SOLR_TIP bin/solr start -c -p 8983 -t data -l logs {code} {code} WRITE specific dirs from Solr/Zk node. SOLR_TIP -----> data -----> [data_dir] Index files [instance_dir] Core properties [zoo_data] Embedded ZK data SOLR_TIP -----> logs All other respective dirs would be READ specific, and changes in them requires NODE restart. {code} Adding support for adding solr.xml if not exist will be helpful. That way, as mentioned above pointing SOLR_HOME to an empty directory would be enough to achieve defined R/W directories. Though intention of writing the patch was to seperate directories which are created / modified after node restart. Default {{SOLR_HOME}} can still point to [SOLR_TIP]/server/solr and picks up default solr.xml. Looking forward to feedback. was (Author: sarkaramr...@gmail.com): Thanks [~janhoy] for the feedback; bq. Looks scary to do SOLR_LOGS_DIR="$(pwd)/$SOLR_LOGS_DIR". It would be better to require the user to configure absolute path here. Sure. I felt supporting relative path makes it a bit easy for deploying multiple Solr nodes on the machine/server. If {{$(pwd)/$SOLR_LOGS_DIR}} is not the right way to do; probably {{SOLR_TIP/$SOLR_LOGS_DIR}}. The absolute path is supported as the original design. bq. In general, I'd prefer of much of the logic regarding folder resolution etc was done in the common SolrCLI.java so as little logic as possible needs to be duplicated in bin/solr and bin/solr.cmd Yeah makes sense. I followed the same resolution criteria implemented for SOLR_HOME, will move that logic to SolrCLI.java. bq. While I believe solr.xml could be created if not exist, I'm not so sure we should go create SOLR_DATA_HOME if it does not exist? Sure. Creating SOLR_DATA_HOME if not exist was again minor improvement for end-user, just like $SOLR_LOGS_DIR, though not necessary. bq. I agree on the goal of making Solr more container friendly and clearly separate what paths can be made R/O and what paths typically need a separate volume mounted. Can you perhaps create a diagram that clearly shows the various directory paths we have today with their defaults and how they will be changed? We intend not to change the default respective directory paths but instead makes it easy to run in a container environment. SOLR_TIP -> solr installation directory Default state: {code} WRITE specific dirs from Solr/Zk node. SOLR_TIP -----> server ------> solr ------> [data_dir] Index files SOLR_TIP -----> server ------> solr ------> [instance_dir] Core properties SOLR_TIP -----> server ------> solr ------> [zoo_data] Embedded ZK data SOLR_TIP -----> server ------> [logs] READ specific contents in the same directory [server/solr] SOLR_TIP -----> server ------> solr ------> solr.xml [changes requires NODE restart] SOLR_TIP -----> server ------> solr ------> [configsets] Default config sets {code} For the below-stated startup command with the current patch; R/W directories will look like following; {code} cd $SOLR_TIP bin/solr start -c -p 8983 -t data -l logs {code} {code} WRITE specific dirs from Solr/Zk node. SOLR_TIP -----> data -----> [data_dir] Index files [instance_dir] Core properties [zoo_data] Embedded ZK data SOLR_TIP -----> logs All other respective dirs would be READ specific, and changes in them requires NODE restart. {code} Adding support for adding solr.xml if not exist will be helpful. That way, as mentioned above pointing SOLR_HOME to an empty directory would be enough to achieve defined R/W directories. Though intention of writing the patch was to seperate directories which are created / modified after node restart. Default {{SOLR_HOME}} can still point to [SOLR_TIP]/server/solr and picks up default solr.xml. Looking forward to feedback. > Utilize solr.data.home / solrDataHome in solr.xml to set all writable files > in single directory > ----------------------------------------------------------------------------------------------- > > Key: SOLR-13035 > URL: https://issues.apache.org/jira/browse/SOLR-13035 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Amrit Sarkar > Priority: Major > Attachments: SOLR-13035.patch, SOLR-13035.patch > > > {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is > already available as per SOLR-6671. > The writable content in Solr are index files, core properties, and ZK data if > embedded zookeeper is started in SolrCloud mode. It would be great if all > writable content can come under the same directory to have separate READ-ONLY > and WRITE-ONLY directories. > It can then also solve official docker Solr image issues: > https://github.com/docker-solr/docker-solr/issues/74 > https://github.com/docker-solr/docker-solr/issues/133 -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org