Merge pull request #2055 from bcbrock/busy628

Busywork updates : 6/28/16

tools/busywork/README.md

@@ -89,8 +89,7 @@ to run a simple stress test. This stress test exercises a single peer
 running `NOOPS` consensus.
 
 At present the PBFT *batch* algorithm is the only true consensus algorithm
-being suported by the development team. (The *classic* and *sieve* algorithms
-may work for some cases.) The target 
+being suported by the development team. The target 
 
     make stress2b
 
@@ -112,6 +111,65 @@ counter (8 bytes) to 1000 counters (8000 bytes):
 	stress2b1k:
             @CORE_PBFT_GENERAL_TIMEOUT_NULLREQUEST=3s \
             $(NETWORK) -batch 4
-            @echo "Sleeping 10 seconds to allow peers to interlock"; sleep 10
+            @echo "makefile: Sleeping 10 seconds to allow peers to interlock"
+			sleep 10
 	        @$(STRESS2) -size 1000
 
+## Running Peers and Clients on Separate Machines
+
+All of the current **busywork** make targets create peer networks and clients
+drivers on the same system. With a little extra work it is possible to run
+**busywork** tools and client drivers targeting arbitrary peer networks. The
+key is that the **busywork** tools and client drivers read the
+[`$BUSYWORK_HOME/network`](bin/README.md#network) and
+[`$BUSYWORK_HOME/chaincodes`](bin/README.md#chaincodes) files to understand
+the peer network configuration.  As long as you or your network setup script
+create a suitable `network` file, and you then place that file in the
+`$BUSYWORK_HOME` directory of the client machine, things will work - subject
+to a few simple considerations discussed below.
+
+### Network Setup Notes
+
+If you want to set up a remote network using the
+[`userModeNetwork`](bin/userModeNetwork) script, then you will probably want
+to use the `-interface` option on the script so that the generated `network`
+file will be usable on the client system. For example,
+
+    userModeNetwork -interface `hostname` -batch 4
+
+will create a `network` file where all of the network interfaces are assigned
+based on the host name of the system. Assuming this host system is accesible
+from the cliant machine you can then simply copy the `network` file from
+host to client machine.
+
+### Client Driver Notes
+
+First, when running a client driver like the `busywork/counters/driver` script,
+you must pass the `-remote` option to the script. This squashes the default
+network watchdog process, which assumes the network is running on the local
+machine. 
+
+A broader issue may be that **busywork** tests are normally one-shot tests
+that start from a clean state, run, check the results, and are done. If
+setting up the peer network is time-consuming, you may want to "re-use" the
+peer network for multiple tests. This is possible in several different ways as
+explained below.
+
+Normally a client driver like the `busywork/counters/driver` script deploys
+chaincodes and then exercises them, every time it runs. However the script
+also includes a `-noDeploy` option that can be used once chaincodes have
+already been deployed in the network by an initial test. In this case the
+script looks at the `$BUSYWORK_HOME/chaincodes` file to determine which
+chaincodes are already available for targeting. All of the correctness
+checking is designed to work under these circumstances.
+
+There is also nothing to prevent running multiple copies of a client driver
+against a single network, other then name collisions that will occur if
+multiple drivers deploy the same chaincodes with the same parameters. The 
+`busywork/counters/driver` now includes the `-ccPrefix` option that allows
+each of multiple client drivers to manipulate chaincodes unique to that
+driver. 
+
+There is currently no support for having multiple client drivers targeting the
+same set of chaincodes (e.g., using `-noDeploy`). The blockchain will
+function, but the corrcetness checks will currently fail.

tools/busywork/bin/Makefile

@@ -62,6 +62,10 @@ behave_tests behave_tests_with_logs
     test suites ('test'). Use 'behave_tests_with_logs' if you want logs from
     the Docker containers.
 
+busyTest
+
+    Run a simple test of the 'busy' script.
+
 
 ############################################################################
 # 'Clean' routines. Note: Docker does not understand that "rm -f" usually
@@ -170,7 +174,7 @@ peer_image:
 ############################################################################
 # Testing
 
-.PHONY: test go_tests behave_tests behave_tests_with_logs
+.PHONY: test go_tests behave_tests behave_tests_with_logs busyTest
 
 go_tests: nosec_noops_1
 	cd $(GOPATH)/src/github.com/hyperledger/fabric; \
@@ -187,6 +191,8 @@ behave_tests_with_logs: fabric_reset
 
 test: go_tests behave_tests
 
+busyTest:
+	./busyTest
 
 ############################################################################
 # "Clean" routines

tools/busywork/bin/README.md

@@ -18,6 +18,11 @@ The following major support scripts are provided. These scripts are called out
 by other major scripts or test drivers. Scripts are typically documented in a
 *usage* string embedded at the top of the script.
 
+* [busy](busy) is a script that can be used to execute operations on any peer
+  network defined by a **busywork** `network` file. Currently the chaincode
+  `deploy`, `invoke` and `query` operations are supported, as well as HTTP GET
+  operations using the REST API.
+
 * [checkAgreement](checkAgreement) is a script that uses the
   [fabricLogger](fabricLogger) (see below) to check that all of the peers in a
   network agree on the contents of the blockchain.
@@ -64,18 +69,26 @@ simple as
     userModeNetwork 10
 
 Several useful options for setting up the network are also provided. Here is
-an example of setting up a 4-node network with security, PBFT Sieve consensus
+an example of setting up a 4-node network with security, PBFT Batch consensus
 and DEBUG-level logging in the peers
 
-    userModeNetwork -security -sieve -peerLogging debug 4
+    userModeNetwork -security -batch -peerLogging debug 4
 
+Normally the peer services are available on all system network interfaces
+(i.e., interface 0.0.0.0). The `-interface` option can be used to limit
+network services to a single interface, and can also be useful for creating
+networks (and `network` files) that will be accessed by client drivers running
+on remote systems.
+
+    userModeNetwork -interface `hostname` 10
+
 Another advantage of a user-mode network can be that the peer processes are
 executed in the environment of the call of
 [userModeNetwork](userModeNetwork). This makes it very easy to override
 default configuration parameters from the command line or from a script. For
 example
 
-    CORE_SECURITY_TCERT_BATCH_SIZE=1000 userModeNetwork -security -sieve 4
+    CORE_SECURITY_TCERT_BATCH_SIZE=1000 userModeNetwork -security -batch 4
 
 
 <a name="caveats"></a>
@@ -109,9 +122,8 @@ and applications create (if necessary) and use `~/.busywork` as the
 in the **BUSYWORK_HOME** depending on which **busywork** tools are being
 used.
 
-* `chaincodes` This file lists chaincode deployments. Each line contains
-  The chaincode name or ID, the chaincode path, the initialization function
-  and its arguments.
+* `chaincodes` This file lists chaincode deployments. The structure of the
+  file is described [below](#chaincodes).
 
 * `dev-vp*-*` If you excute the `make cclogs` target of the
   [Makefile](Makefile) the chaincode logs will be dumped into these
@@ -154,7 +166,7 @@ used.
     "date": "2016/05/27+08:15:45",
     "createdBy": "userModeNetwork",
     "security": "true",
-    "consensus": "sieve",
+    "consensus": "batch",
     "peerProfileServer": "true",
     "membersrvc":
         { "service": "0.0.0.0:50051",
@@ -199,3 +211,29 @@ used.
     ]
 }
 ```
+
+<a name="chaincodes"></a>
+## *busywork* Chaincode Deployments
+
+**busywork** scripts that deploy chaincodes to a peer network produce a
+  description of the deployments for the benefit of other **busywork**
+  tools. The deployment information is written as `$BUSYWORK_HOME/chaincodes`,
+  and contains a single JSON object. This is still a work in progress so some
+  fields may be changed and/or added in the future, but this is an example of
+  what one of these chaincode deployment descriptions looks like at present.
+```
+{
+    "cc0"     : {
+        "name"     : "a3a4756cd347784d15262a5839838768cd1ef8d6f853893e64651a788c30c409d1a0e645c230c2a3142abed8699f3435ce5a5bacc1282d630866b949f69d6773",
+        "path"     : "github.com/hyperledger/fabric/tools/busywork/counters",
+        "function" : "parms",
+        "args"     : ["-id","cc0"]
+    },
+    "cc1" : {
+        "name"     : "52676ae63ebf205f0c9a2dba111a2ac75afaf62075e43b21e04ccbf29ce2e9661a6eb9963cc29cf2f38e9b12fff0c00fcb9b9e98c0fb342bb5a7eb299c6dc938",
+        "path"     : "github.com/hyperledger/fabric/tools/busywork/counters",
+        "function" : "parms",
+        "args"     : ["-id","cc1"]
+    }
+}
+```