[jira] [Updated] (SOLR-7850) Move user customization out of solr.in.* scripts
[
https://issues.apache.org/jira/browse/SOLR-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-7850:
---
Assignee: David Smiley
Fix Version/s: 6.3
> Move user customization out of solr.in.* scripts
>
>
> Key: SOLR-7850
> URL: https://issues.apache.org/jira/browse/SOLR-7850
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>Assignee: David Smiley
>Priority: Minor
> Fix For: 6.3
>
> Attachments:
> SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch,
> SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch
>
>
> I've seen a fair number of users customizing solr.in.* scripts to make
> changes to their Solr installs. I think the documentation suggests this,
> though I haven't confirmed.
> One possible problem with this is that we might make changes in those scripts
> which such a user would want in their setup, but if they replace the script
> with the one in the new version, they will lose their customizations.
> I propose instead that we have the startup script look for and utilize a user
> customization script, in a similar manner to linux init scripts that look for
> /etc/default/packagename, but are able to function without it. I'm not
> entirely sure where the script should live or what it should be called. One
> idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of
> thought into it yet.
> If the internal behavior of our scripts is largely replaced by a small java
> app as detailed in SOLR-7043, then the same thing should apply there -- have
> a config file for a user to specify settings, but work perfectly if that
> config file is absent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7850) Move user customization out of solr.in.* scripts
[
https://issues.apache.org/jira/browse/SOLR-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-7850:
---
Attachment: SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch
Here's an updated patch that addresses the Windows side. I also did a little
tweaking to make the declaration order a little more consistent between the
Bash & Windows scripts. I did a little testing in Windows but I should do more.
[~janhoy] might you take a look please?
> Move user customization out of solr.in.* scripts
>
>
> Key: SOLR-7850
> URL: https://issues.apache.org/jira/browse/SOLR-7850
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments:
> SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch,
> SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch
>
>
> I've seen a fair number of users customizing solr.in.* scripts to make
> changes to their Solr installs. I think the documentation suggests this,
> though I haven't confirmed.
> One possible problem with this is that we might make changes in those scripts
> which such a user would want in their setup, but if they replace the script
> with the one in the new version, they will lose their customizations.
> I propose instead that we have the startup script look for and utilize a user
> customization script, in a similar manner to linux init scripts that look for
> /etc/default/packagename, but are able to function without it. I'm not
> entirely sure where the script should live or what it should be called. One
> idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of
> thought into it yet.
> If the internal behavior of our scripts is largely replaced by a small java
> app as detailed in SOLR-7043, then the same thing should apply there -- have
> a config file for a user to specify settings, but work perfectly if that
> config file is absent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7850) Move user customization out of solr.in.* scripts
[
https://issues.apache.org/jira/browse/SOLR-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-7850:
---
Attachment: SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch
Here's a patch:
* SOLR_HEAP: it was already defaulted
* GC_LOG_OPTS: moved the default to bin/solr
* GC_TUNE: moved the default to bin/solr
* ENABLE_REMOTE_JMX_OPTS: it was already defaulted
* \-Xss256k: moved to bin/solr as a new SOLR_STACK_SIZE var since we want it
appended to SOLR_OPTS
And then, a few minutes ago, it hits me there's the Windows side to worry about
-- argh! I'm looking forward to Jan's progress on SOLR-7871 :-)
Unless someone wants to help me with the Windows side... perhaps I could reduce
the scope to the most simplest case where it was *already* defaulted: SOLR_HEAP
and ENABLE_REMOTE_JMX_OPTS ?
> Move user customization out of solr.in.* scripts
>
>
> Key: SOLR-7850
> URL: https://issues.apache.org/jira/browse/SOLR-7850
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments:
> SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch
>
>
> I've seen a fair number of users customizing solr.in.* scripts to make
> changes to their Solr installs. I think the documentation suggests this,
> though I haven't confirmed.
> One possible problem with this is that we might make changes in those scripts
> which such a user would want in their setup, but if they replace the script
> with the one in the new version, they will lose their customizations.
> I propose instead that we have the startup script look for and utilize a user
> customization script, in a similar manner to linux init scripts that look for
> /etc/default/packagename, but are able to function without it. I'm not
> entirely sure where the script should live or what it should be called. One
> idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of
> thought into it yet.
> If the internal behavior of our scripts is largely replaced by a small java
> app as detailed in SOLR-7043, then the same thing should apply there -- have
> a config file for a user to specify settings, but work perfectly if that
> config file is absent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
