geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbarr...@apache.org
Subject [1/3] geode git commit: GEODE-2332: Deleted deprecated tests scripts.
Date Sat, 21 Jan 2017 20:39:22 GMT
Repository: geode
Updated Branches:
  refs/heads/next-gen-native-client-software-grant 86df4a7c2 -> 03781bd1c


http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/using_runCSDriver
----------------------------------------------------------------------
diff --git a/src/tests/cpp/scripts/using_runCSDriver b/src/tests/cpp/scripts/using_runCSDriver
deleted file mode 100644
index d99d463..0000000
--- a/src/tests/cpp/scripts/using_runCSDriver
+++ /dev/null
@@ -1,161 +0,0 @@
-This file contains the setup and usage instructions for running the C#
-XML framework.
-
- 1. Ensure that .NET 2.0 runtime is installed on the client machines (available here:
-      http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en)
-
- 2. By default it uses plink to start clients on remote machines. So download plink.exe
-    and put it in your path. (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html).
-    Alternatively it can use passwordless ssh with public-key authentication by
-    specifying the "--auto-ssh" option. For this to work on Windows, the sshd daemon
-    must run as a domain admin user who has the permissions to access network shares
-    and other resources. For more information on configuring this mode see this:
-    http://ist.uwaterloo.ca/~kscully/CygwinSSHD_W2K3.html
-
- 3. Run the script setCLITrust.bat on all the windows machines where
-    clients will be created. This script is inside tests/scripts directory
-    of ThinClient branch.
-
- 4. Ensure that the user has permission to be able to create shares on the
-    machine where driver shall be invoked.
-
- 5. When using local console login (or RDP) run OS_BUILD_DIR/framework/csharp/bin/FwkDriver.exe
-    Usage: FwkDriver [OPTION] [<host1> ...]
-      <host1> ... are (optional) hostnames of the machines on which to
-       distribute the clients. Each host can optionally have the hostGroup
-       name prefixed to it with ':' e.g. CS:host1; the hostGroup should not
-       be '*' which implicitly stands for all hosts
-    Options are:
-      --xml=FILE     An XML file having the test to be executed.
-                     This option can be specified multiple times
-      --list=FILE    A file containing a list XML files having the tests to be executed
-      --pool=POOLOPTION  where POOLOPTIONs are poolwithendpoints/poolwithlocator to run the
existing tests with pool option.
-      --at=TIME      The time at which to execute the regression test
-      --auto-ssh     Use ssh configured for passwordless login instead of plink as remote
shell
-                     Note that this shall only work if sshd is running as a domain user having
-                     permissions to access network shares and other resources on given hosts.
-      --bbServer=HOST:PORT  The <host>:<port> to use for connecting to
-                            external TCP BlackBoard server. This is to be used
-                            when an external BBserver is being used instead
-                            of the internal one.
-      --bbPasswd     Use the external BBserver to get the passwords.
-      --driverPort   The port to use for running the Driver service.
-
-    At least one XML file should be specified using one of --xml or --list options
-    Both options can be provided in which case all the specified tests in
-    both will be run.
-
-    The --bbServer, --bbPasswd, --driverPort options should never be specified
-    directly since they are only useful when launching it through external
-    scripts like runCSDriver.sh
-
- 6. When using a ssh session run OS_BUILD_DIR/framework/csharp/bin/runCSDriver.sh.
-    Usage: runCSDriver.sh [OPTION] [<host1> ...]
-      <host1> ... are (optional) hostnames of the machines on which to
-       distribute the clients. Each host can optionally have the hostGroup
-       name prefixed to it with ':' e.g. CS:host1; the hostGroup should not
-       be '*' which implicitly stands for all hosts
-    Options are:
-      --xml=FILE     An XML file having the test to be executed.
-                     This option can be specified multiple times
-      --list=FILE    A file containing a list XML files having the tests to be executed
-      --pool=POOLOPTION  where POOLOPTIONs are poolwithendpoints/poolwithlocator to run the
existing tests with pool option.
-      --database     This to be used for upload the data in database for regression history.
Need to be mentioned at every regression run.
-      --at=TIME      The time at which to execute the regression test
-      --auto-ssh     Use ssh configured for passwordless login instead of plink as remote
shell
-                     Note that this shall only work if sshd is running as a domain user having
-                     permissions to access network shares and other resources on given hosts.
-
-    At least one XML file should be specified using one of --xml or --list options
-    Both options can be provided in which case all the specified tests in
-    both will be run.
-
-
-Example usage:
-
-  OS_BUILD_DIR/framework/csharp/bin/FwkDriver --list=nativeNightly.list CS:pc33 CS:pc34 pc34
pc35 pc36 pc37 pc38
-or
-  OS_BUILD_DIR/framework/csharp/bin/runCSDriver.sh --list=nativeNightly.list CS:pc33 CS:pc34
pc34 pc35 pc36 pc37 pc38
-
-With Pool Option:
-   OS_BUILD_DIR/framework/csharp/bin/FwkDriver --pool=poolwithendpoints --list=nativeNightly.list
CS:pc33 CS:pc34 pc34 pc35 pc36 pc37 pc38
-or 
-   OS_BUILD_DIR/framework/csharp/bin/FwkDriver --pool=poolwithlocator --list=nativeNightly.list
CS:pc33 CS:pc34 pc34 pc35 pc36 pc37 pc38
-
-Note that the XML file path (given in --xml option or inside the list) should
-be relative to base xml directory like in C++.
-The list file itself should be the path relative to the current directory.
-
-The current directory can contain a gfcsharp.properties or gfcpp.properties
-file to set the default properties for the clients (preference is in the
-given order). The following variables can be set in file "gfcsharp.env" in the
-current directory (line starting with # indicates a comment and is ignored):
- 
-  FWK_WINLOGDIR="...":
-      root of the path where the logs have to be created in Windows notation
-  FWK_UNIXLOGDIR="...":
-      root of the path where unix cacheserver logs have to be created in
-      Unix notation; this is required when starting the cacheserver on a
-      UNIX machine (more on this below) and should point to the same
-      directory as FWK_WINLOGDIR for it to work correctly
-  GFE_DIR="...":
-      the path of the UNIX java cacheserver product; required when one of
-      server client machine lists a UNIX machine
-  GFE_CLASSPATH="...":
-      any additional CLASSPATH for the UNIX java cacheservers
-  GF_JAVA="..."
-      Provied the java path ( e.g. /gcm/where/jdk/1.6.0_7/x86_64.linux/bin/java ).
-  GF_JAVA.WIN="..."
-      Provide the java path for windows to execute LatestProp class file( e.g. //inf1/shared/jdk/1.6.0_7/x86_64.linux/bin/java
).
-  GFE_DIR.WIN="..."
-      Provide java cacheserver product path for windows to execute LatestProp class file
( e.g. //bass/bass1/users/rkumar/project/trunk/product ).
-      
-
-Note that the gfcsharp.env is not a shell script and no "export" or other
-commands should be given. Any other environment variables like CLASSPATH
-can also be provided here (note that the local path for the jars can be
-provided in CLASSPATH since that shall be converted to the share format
-by the framework automatically) or other environment variables specified
-in OS_BUILD_DIR/framework/csharp/bin/run.env can be overridden here.
-The double quotes around the values are optional even if there are spaces.
-
-If no FWK_WINLOGDIR is provided then by default the logs will be created
-in OS_BUILD_DIR/tests/results/csharpfwk. A subdirectory named
-FwkCS_<timestamp directory> shall be created that contains the logs for a
-particular run and a link to the latest timestamp directory will also be
-created. There will be separate sub directories created for separate XMLs
-inside this directory, and each sub-directory for an XML will contain a
-separate sub-directory for each test listed in the XML. The directory name
-will be the name of the test. The top-level directory shall contain a
-Driver.log file which records all the actions taken by the driver in that
-particular run, and at the end of the run an error.report shall be generated
-inside the top-level directory as well as inside each of the XML sub-directories.
-
-Using C# framework it is possible to launch java servers on linux/solaris machines as follows:
-
-    * Specify FWK_LOGDIR.WIN and FWK_LOGDIR.LIN/FWK_LOGDIR.SUN to point to the same
-      network directory (e.g. //ns320/users/swale/csresults and /home/swale/csresults
-      respectively) in gfcsharp.env
-    * Specify the GFE_DIR.LIN/GFE_DIR.SUN to point to the location of unix cacheserver
-      (e.g. /gcm/where/cplusplus/thirdparty/linux/gfe/product) in gfcsharp.env
-      For each of the above variables use <var>.<host type> where host type can
-      be one of WIN, LIN or SUN
-    * Now you can use any unix hostname for the CS hostgroup. However, note that
-      there should be at least one windows machine in that hostgroup that will
-      actually run the C# code that will perform setup/start/stop of
-      cacheservers remotely. For example:
-       FwkDriver --xml=Native/failoverTest.xml CS:bass CS:trout CS:pc34 pc31 pc32
-    * To ensure that all servers are started on linux servers use the first
-      host as windows one and all others as linux ones. The framework has been
-      modified so as to start choosing the servers to use from the second one
-      in the list. Also it means that the number of linux hosts in the CS hostgroup
-      should be equal to the number of clients being started in that group,
-      otherwise cycling of clients among hosts will cause servers to be
-      started on windows hosts. For example:
-        FwkDriver --xml=RemoteQuery/failoverQueryTest.xml CS:pc33 CS:bass CS:trout pc33 pc34
pc36
-      This will start JCS1 on pc33 but the actual servers shall be launched
-      from the second server in the host-group list i.e. bass, so that the two 
-      servers will be started on bass and trout respectively from pc33, while
-      other clients will be launched on pc33/pc34/pc36
-This is useful for regressions where windows servers can go OutOfMemory
-due to limited amount of available memory.

http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/using_runDriver
----------------------------------------------------------------------
diff --git a/src/tests/cpp/scripts/using_runDriver b/src/tests/cpp/scripts/using_runDriver
deleted file mode 100644
index c9fcee0..0000000
--- a/src/tests/cpp/scripts/using_runDriver
+++ /dev/null
@@ -1,166 +0,0 @@
-This file describes the command line arguments used by the runDriver script,
-the files that may be used as values for some of the command line arguments,
-and shows some common uses for runDriver.
-
-First the arguments runDriver accepts:
-
-This option indicates that the debug build executables and libraries should be 
-used. This will affect the paths used in setting PATH and LD_LIBRARY_PATH.
-  -D
-
-These next four all cause valgrind to be used, and each will cause a different tool
-to be used. These are mutually exclusive, but the script does not error out.
-It is simply a "first one wins" situation. After the tool to use has been set,
-subsequent options that would otherwise set are just ignored.
-You should just use one of these next four options:
-  -M -- use valgrind with memcheck
-  -C -- use valgrind with cachegrind
-  -H -- use valgrind with massif
-  -P -- use valgrind with callgrind
-
-This option allows you to specify a particular xml test file to include in the run.
-This option may be used multiple times, and can be used in addition to the -l option.
-The xml file should have path information relative to the <build_results>/framework/xml
directory.
-  -x <xml file> 
-
-This option allows you to specify a text file containing a number of text xml files.
-Each xml file in this file will be added to the test, just as though it had been
-specified using the -x option. This means the path relative to ..../framework/xml
-is required. This is used for regression testing.
-  -l <file containing names of xml files> -
-
-This option specifies how many times each test should be run. Each xml test file
-will be processed this number of times. The default is 1. This is used in perf testing
-where a single run is not adequate to generate reliable numbers.
-  -r <n>  
-
-This option causes the framework to start a unicast locator for topic resolution,
-nstead of using the default multicast topic resolution. This will cause a 
-different locator to be used for each run of an xml test, to prevent pollution 
-from leftover processes that the framework failed to kill.
-  -u
-
-This option causes the framework to start the test with pool along with the specified pool
option
-  -p <pool option>
-where <pool option>= poolwithendpoints/poolwithlocator
-
-This option causes the test to use statically built executables and libraries,
-instead of the dynamically linked. This is used in regression tests to make sure
-both types are tested. This will affect the paths used in setting PATH 
-and LD_LIBRARY_PATH.
-  -s 
-
-This option allows valgrind to be used with only the clients specified, 
-instead of trying to run all client under valgrind. This option can be specified
-multiple times, allowing any number of clients to be run under valgrind.
-  -t client_id
-
-The next three options allow you specify the location of the build to use on a
-particular OS. The platform that runDriver is executed on will default to the
-build that runDriver is being executed out of. The specification is in the form
-of hostname:absolute_path_to_build with the directory above product being the 
-location to specify.
-  -L <host>:<build_location> -- linux build to use
-  -S <host>:<build_location> -- solaris build to use
-  -W <host>:<build_location> -- windows build to use
-
-This option allows you to specify the location of the valgrind install. 
-Not very sophisticated, only one location is active for a entire test run. 
-The default location is /gcm/where/cplusplus/perftools/valgrind.
-  -V path_to_valgrind
-
-This option allows you to specify what directory will be used as the base location
-for the test run, all files and directories created as part of the run will be 
-under this location. 
-The default is the current working directory when runDriver is invoked.
-  -d test_directory 
-
-This option allows email recipients to be specified. The content of the error.report
-file for the entire test run will be emailed to the specified recipients.
-This option may be used multiple times to specify multiple recipients.
-  -m mail_address 
-
-This option allows you to specify a file containing additional command line
-arguments. Its purpose is to allow you place common, or lengthy arguments into
-a file, and use that file whenever appropriate by using this option. Any
-argument is allowed, with the exception of hostnames, as they do not have a option
-that prefaces them. You can include the -h option that specifies a file with host
-names in it. The file is consumed and its arguments processed as soon as it is 
-encountered on the commandline. So where it appears relative to other command line
-options may be important. This option may be used multiple times. You could have
-different options files for different purposes, and they may be used in 
-conjunction with each other at times.
-  -o options_file  
-
-It is important to note some behaviors that result from using an options file. 
-Some arguments are "last one wins" arguments, others are "first one wins", this 
-causes the order of the arguments on the command line relative to the -o option 
-to be important. Some arguments cannot be unset, such as the -D, -M, etc options. 
-If you set this in an options file, you cannot override it on the command line, 
-even after the -o. Some arguments can appears many times, their content 
-aggregating with the previous occurances. This prevents you from overriding 
-something like email recipients on the command line. Whatever is on the command 
-line is simply added to anything that may have been specified through the use of 
-the -o option.
-
-This option allows you to place the hosts you wish to use into a file, and just 
-specify that file on the command line.
-  -h <file_containing_host_name> 
-  
-Lastly, rundriver expects all arguments after the options to be host names to 
-use in the test. It aggregates these names with any hosts that might have been
-specified using the -h option. If no host are specified in either manner, the
-host runDriver is executing on will be the only host used in the test.
-  host list 
-
-This option allows you to upload the regression results into database table to keep the regression
history.
-  -R
-Some examples of runDriver use:
-
-~/mybuild/framework/scripts/runDriver -x Misc/quickTest.xml \
-  -W tkeith-desk:/cygdrive/C/Temp/Built/trunk tiny tkeith-desk hs20a
-
-This is an example of needing to run a single test, using the current working 
-directory as the test directory, and using a mix of linux and windows machines.
-
-
-~/mybuild/framework/scripts/runDriver -x Perf/perfBenchmark.xml -r 10 \
-  -h grid_machines.txt
-
-Is an example of how runDriver could be used to run perfBenchmark 10 times on a 
-set of machines in an Intel ( or other vendor ) lab.
-
-~/mybuild/framework/scripts/runDriver -x Native/getAll.xml -p poolwithendpoints bensa
-
-~/mybuild/framework/scripts/runDriver -x Native/getAll.xml -p poolwithlocator bensa
-
-~/mybuild/framework/scripts/runDriver -x Native/getAll.xml bensa
-
-The above 3 examples  will enable the xmls to run with pool with various pool options ie

-The 1st one will run with pool,with serverendpoints
-2nd one with pool,with locators and
-3rd will run without pool which is the default.
-
-/export/tiny1/users/tkeith/regression/framework/scripts/runDriver \
-  -l short_nightly.list \
-  -h /export/tiny2/users/tkeith/regression/regHostsA.txt \
-  -o /export/tiny2/users/tkeith/regression/regEmail.txt \
-  -o /export/tiny2/users/tkeith/regression/regBuilds.txt
-
-This is an example of how it might be used for regression runs. 
-The list of xml tests are in /export/tiny1/users/tkeith/regression/framework/xml/short_nightly.list
-and the list of hosts to use is in regHostsA.txt
-and the list of email recipients is in regEmail.txt
-and the builds to use in the regression run are in regBuilds.txt.
-
-
-It is important to note that runDriver has no option to do an git pull and
-clean build. This is handled by the runBuild script. In a cron, it should be run 
-prior to the regression test themselves, allowing enough time for it to complete 
-prior to the regression tests starting.
-
-
-The files specified by the -o -h and -l options are allowed to have comments.
-The comments are indicated by a # symbol. The contents of these files 
-will have everything between a # and the end of line, stripped before the 
-file is consumed. this allows trailing comments in addition to whole line comments.

http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/using_scalePerfDriver
----------------------------------------------------------------------
diff --git a/src/tests/cpp/scripts/using_scalePerfDriver b/src/tests/cpp/scripts/using_scalePerfDriver
deleted file mode 100644
index c1ace97..0000000
--- a/src/tests/cpp/scripts/using_scalePerfDriver
+++ /dev/null
@@ -1,6 +0,0 @@
-#Steps to run yet to come.
-#use runScalePerf script for cpp run
-Example for cpp run: Need 8 hosts to run the tests
-/export/w1-gst-dev01a/users/rkumar/project/ThinClient/build-artifacts/linux/framework/scripts/runScalePerf
/export/w1-gst-dev01a/users/rkumar/project/ThinClient/build-artifacts/linux /export/gcm/where/jdk/1.6.0_26/x86_64.linux/bin/java
/gcm/where/gemfire/70/snaps.Any/snapshots.34944/gf70MAINTsancout/product . w1-gst-dev01 w1-gst-dev02
w1-gst-dev03 w1-gst-dev04 w1-gst-dev05 w1-gst-dev06 w1-gst-dev07 w1-gst-dev08
-#use FwkDriver.exe for c# run
-OS_BUILD_DIR/framework/csharp/bin/FwkDriver.exe --list=scale.list CS1:w1-gst-dev01 CS1:w1-gst-dev02
CS1:w1-gst-dev03 CS1:w1-gst-dev04 CS2:w1-gst-dev05 CS2:w1-gst-dev06 CS3:w1-gst-dev07 CS3:w1-gst-dev08

http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/waitForBBKey.sh
----------------------------------------------------------------------
diff --git a/src/tests/cpp/scripts/waitForBBKey.sh b/src/tests/cpp/scripts/waitForBBKey.sh
deleted file mode 100755
index 3d97a4a..0000000
--- a/src/tests/cpp/scripts/waitForBBKey.sh
+++ /dev/null
@@ -1,26 +0,0 @@
-#!/bin/bash
-
-[ "$#" -gt 3 -o "$#" -lt 2 ] && echo "`basename "$0"`: Incorrect number[$#] of args:
$@." && exit 1
-
-# maximum wait for 30min if no time is given
-maxSecs=1800
-[ "$#" -eq 3 ] && maxSecs="$3"
-
-bbVal="`FwkBB get "$1" "$2" 2>/dev/null`"
-numIters=1
-while [ -z "${bbVal}" ]; do
-  sleep 1
-  if [ "${numIters}" -ge "${maxSecs}" ]; then
-    break
-  fi
-  ((numIters++))
-  bbVal="`FwkBB get "$1" "$2" 2>/dev/null`"
-done
-
-echo ${bbVal}
-
-if [ -z "${bbVal}" ]; then
-  exit 1
-else
-  exit 0
-fi

http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/waitForTask.sh
----------------------------------------------------------------------
diff --git a/src/tests/cpp/scripts/waitForTask.sh b/src/tests/cpp/scripts/waitForTask.sh
deleted file mode 100755
index 8a86965..0000000
--- a/src/tests/cpp/scripts/waitForTask.sh
+++ /dev/null
@@ -1,72 +0,0 @@
-#!/bin/bash
- 
-export local=`hostname`
-export GF_FQDN=`nslookup $local 2>/dev/null | ${AWK:-awk} '/^Name:/{print $2}'`
-
-tag=""
-numClients=1
-while getopts ":t:c:p:m:" op
-do
-  case $op in
-   ( "m" ) ((scnt++)) ; waitMinutes="$OPTARG" ;;
-   ( "t" ) ((scnt++)) ; tag="$OPTARG" ;;
-   ( "c" ) ((scnt++)) ; numClients="$OPTARG" ;;
-   ( "p" ) ((scnt++)) ; seqid="$OPTARG" ;;
-    ( * ) echo "Unknown argument provided: -$OPTARG, ignoring." ; echo "" ;;
-  esac
-  ((scnt++))
-done
-
-while [ ${scnt:-0} -gt 0 ]
-do
-  shift
-  ((scnt--))
-done
-
-# Where are we now?
-currDir=`pwd`
-bnam=`basename $currDir`
-
-mkdir -p ../pids/$GF_FQDN/$bnam
-echo "${$}" > ../pids/$GF_FQDN/$bnam/waitForTask_pid
-
-# cnt specified which client to setup:
-cnt=$numClients
-
-# Base for dir names
-gfdb=GFEJC${tag:+_}$tag
-
-tdir=${gfdb}_$cnt
-if [ ! -d $tdir ]
-then
-  echo $tdir does not exist.
-  exit 0
-fi
-
-grep "seqid $seqid finished" $currDir/$tdir/JC${tag:+_}$tag${cnt:+_}$cnt.log
-status=$?
-num=0
-sleepTime=10  ## Note: changing this impacts the calculation used to set sleepsPerMinute
-sleepsPerMinute=6
-((limit=$waitMinutes*$sleepsPerMinute))
-((logLimit=$limit/3))
-while [ $status -ne 0 ]
-do 
-  sleep $sleepTime
-  ((num++))
-  if [ $num -gt $limit ]
-  then
-    echo "ERROR:  Wait for task timed out after $waitMinutes minutes."
-    exit 1
-  fi
-  ((val=$num%$logLimit))
-  if [ $val -eq 0 ]
-  then
-    ((minutes=$num/$sleepsPerMinute))
-    echo "Wait for task has waited for $minutes minutes."
-  fi
-  grep "seqid $seqid finished" $currDir/$tdir/JC${tag:+_}$tag${cnt:+_}$cnt.log
-  status=$?
-done
-
-exit 0


Mime
View raw message