[
https://issues.apache.org/jira/browse/SOLR-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930068#comment-16930068
]
Gus Heck edited comment on SOLR-11492 at 9/15/19 7:46 PM:
----------------------------------------------------------
Just peeked at the scripts in /solr/cloud-dev and there seem to be 3 things
going on here
# A series of example scripts - these are very hard coded to blow everything
away on every start and always recompile everything. The also appear to be
trying to get 3 internal zk's (-Dzkrun) to be a cluster
## example1.sh
## example2.sh
## example3.sh
# A series of scripts that appear to want to work together, using a single
-Dzkrun zookeeper, accepting existing $JAVA_OPTS, can either wipe/recompile or
start without wipe/recompile (but cant recompile and not wipe).
## clean.sh
## solrcloud-start.sh
## solrcloud-start-existing.sh
## stop.sh
# A pair of scripts - seem to have many of the capabilities of cloud.sh, but
only creates a single node. Has cleanlogs/taillogs/createshard functions that
cloud.sh has
## control.sh
## functions.sh
All of the above are driving startup directly via calling java -jar start.jar
and won't receive the benefits/restrictions/whatever from our mainline
start/stop scripts. Additionally none of the above open debugging ports.
Setting that in JAVA_OPTS would fail because the port would be the same for
every node... Also all of these are made to be run from *inside* the checkout
which means that all the logs/data/etc are in the checkout and would fail
precommit as files not under source control... also the various rm -r -f
commands sprinkled around those scripts are that much more hazardous if run
from within the checkout.
Another big difference is that all of the above only support having one cloud
setup available at a time whereas cloud.sh allows you to keep old setups as
long as you like.
So I think I'm going to nominate all of them for deletion in favor of the
cloud.sh that is being added in this ticket unless someone is attached to them
and speaks up in their defense in the next few days.
was (Author: gus_heck):
Just peeked at the scripts in /solr/cloud-dev and there seem to be 3 things
going on here
# A series of example scripts - these are very hard coded to blow everything
away on every start and always recompile everything. The also appear to be
trying to get 3 internal zk's (-Dzkrun) to be a cluster
## example1.sh
## example2.sh
## example3.sh
# A series of scripts that appear to want to work together, using a single
-Dzkrun zookeeper, accepting existing $JAVA_OPTS, can either wipe/recompile or
start without wipe/recompile (but cant recompile and not wipe).
## clean.sh
## solrcloud-start.sh
## solrcloud-start-existing.sh
## stop.sh
# A pair of scripts - seem to have many of the capabilities of cloud.sh, but
only creates a single node. Has cleanlogs/taillogs/createshard functions that
cloud.sh has
## control.sh
## functions.sh
All of the above are driving startup directly via calling java -jar start.jar
and won't receive the benefits/restrictions/whatever from our mainline
start/stop scripts. Additionally none of the above open debugging ports.
Setting that in JAVA_OPTS would fail because the port would be the same for
every node... Also all of these are made to be run from *inside* the checkout
which means that all the logs/data/etc are in the checkout and would fail
precommit as files not under source control... also the various rm -r -f
commands sprinkled around those scripts are that much more hazardous if run
from within the checkout. So I think I'm going to nominate all of them for
deletion in favor of the cloud.sh that is being added in this ticket unless
someone is attached to them and speaks up in their defense in the next few days.
> More Modern cloud dev script
> ----------------------------
>
> Key: SOLR-11492
> URL: https://issues.apache.org/jira/browse/SOLR-11492
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Affects Versions: 8.0
> Reporter: Gus Heck
> Assignee: Gus Heck
> Priority: Minor
> Attachments: cloud.sh, cloud.sh, cloud.sh, cloud.sh, cloud.sh,
> cloud.sh
>
>
> Most of the scripts in solr/cloud-dev do things like start using java -jar
> and other similarly ancient techniques. I recently decided I really didn't
> like that it was a pain to setup a cloud to test a patch/feature and that
> often one winds up needing to blow away existing testing so working on more
> than one thing at a time is irritating... so here's a script I wrote, if
> folks like it I'd be happy for it to be included in solr/cloud-dev
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
