test-network-k8s: Some minor improvements (#718)

This patch includes some minor improvements, such as:
- Fix typos and broken links
- Correct chaincode type of asset-transfer-basic-debug
  (seems it should be ccaas)

Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>

test-network-k8s/chaincode/asset-transfer-basic-debug/metadata.json

@@ -1,4 +1,4 @@
 {
-  "type": "external",
+  "type": "ccaas",
   "label": "basic_1.0"
 }

test-network-k8s/config/org0/fabric-ca-server-config.yaml

@@ -31,7 +31,7 @@
 #   For example, see "tls.certfile" and "tls.clientauth.certfiles".
 #   The value of each of these fields can be a simple filename, a
 #   relative path, or an absolute path.  If the value is not an
-#   absolute path, it is interpretted as being relative to the location
+#   absolute path, it is interpreted as being relative to the location
 #   of this configuration file.
 #
 #############################################################################
@@ -341,7 +341,7 @@ idemix:
   rhpoolsize: 1000
 
   # The Idemix credential issuance is a two step process. First step is to  get a nonce from the issuer
-  # and second step is send credential request that is constructed using the nonce to the isuser to
+  # and second step is send credential request that is constructed using the nonce to the issuer to
   # request a credential. This configuration property specifies expiration for the nonces. By default is
   # nonces expire after 15 seconds. The value is expressed in the time.Duration format (see https://golang.org/pkg/time/#ParseDuration).
   nonceexpiration: 15s
@@ -498,9 +498,9 @@ metrics:
     # statsd server address
     address: 127.0.0.1:8125
 
-    # the interval at which locally cached counters and gauges are pushsed
+    # the interval at which locally cached counters and gauges are pushed
     # to statsd; timings are pushed immediately
     writeInterval: 10s
 
-    # prefix is prepended to all emitted statsd merics
+    # prefix is prepended to all emitted statsd metrics
     prefix: server

test-network-k8s/config/org1/fabric-ca-server-config.yaml

@@ -31,7 +31,7 @@
 #   For example, see "tls.certfile" and "tls.clientauth.certfiles".
 #   The value of each of these fields can be a simple filename, a
 #   relative path, or an absolute path.  If the value is not an
-#   absolute path, it is interpretted as being relative to the location
+#   absolute path, it is interpreted as being relative to the location
 #   of this configuration file.
 #
 #############################################################################
@@ -341,7 +341,7 @@ idemix:
   rhpoolsize: 1000
 
   # The Idemix credential issuance is a two step process. First step is to  get a nonce from the issuer
-  # and second step is send credential request that is constructed using the nonce to the isuser to
+  # and second step is send credential request that is constructed using the nonce to the issuer to
   # request a credential. This configuration property specifies expiration for the nonces. By default is
   # nonces expire after 15 seconds. The value is expressed in the time.Duration format (see https://golang.org/pkg/time/#ParseDuration).
   nonceexpiration: 15s
@@ -498,9 +498,9 @@ metrics:
     # statsd server address
     address: 127.0.0.1:8125
 
-    # the interval at which locally cached counters and gauges are pushsed
+    # the interval at which locally cached counters and gauges are pushed
     # to statsd; timings are pushed immediately
     writeInterval: 10s
 
-    # prefix is prepended to all emitted statsd merics
+    # prefix is prepended to all emitted statsd metrics
     prefix: server

test-network-k8s/config/org2/fabric-ca-server-config.yaml

@@ -31,7 +31,7 @@
 #   For example, see "tls.certfile" and "tls.clientauth.certfiles".
 #   The value of each of these fields can be a simple filename, a
 #   relative path, or an absolute path.  If the value is not an
-#   absolute path, it is interpretted as being relative to the location
+#   absolute path, it is interpreted as being relative to the location
 #   of this configuration file.
 #
 #############################################################################
@@ -341,7 +341,7 @@ idemix:
   rhpoolsize: 1000
 
   # The Idemix credential issuance is a two step process. First step is to  get a nonce from the issuer
-  # and second step is send credential request that is constructed using the nonce to the isuser to
+  # and second step is send credential request that is constructed using the nonce to the issuer to
   # request a credential. This configuration property specifies expiration for the nonces. By default is
   # nonces expire after 15 seconds. The value is expressed in the time.Duration format (see https://golang.org/pkg/time/#ParseDuration).
   nonceexpiration: 15s
@@ -498,9 +498,9 @@ metrics:
     # statsd server address
     address: 127.0.0.1:8125
 
-    # the interval at which locally cached counters and gauges are pushsed
+    # the interval at which locally cached counters and gauges are pushed
     # to statsd; timings are pushed immediately
     writeInterval: 10s
 
-    # prefix is prepended to all emitted statsd merics
+    # prefix is prepended to all emitted statsd metrics
     prefix: server

test-network-k8s/docs/CHAINCODE.md

@@ -31,8 +31,8 @@ $ ./network chaincode query '{"Args":["ReadAsset","1"]}' | jq
 
 ## Running Smart Contracts on Kubernetes 
 
-In the Kubernetes Test Network, smart contracts are developed with the [Chaincode as a Service](link)
+In the Kubernetes Test Network, smart contracts are developed with the [Chaincode as a Service](https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html)
-pattern, relying on an embedded [External Builder](link) to avoid the use of a Docker daemon. With 
+pattern, relying on an embedded [External Builder](https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html) to avoid the use of a Docker daemon. With 
 Chaincode-as-a-Service, smart contracts are deployed to Kubernetes as `Services`,
 `Deployments`, and `Pods`.  When invoking smart contracts, the Peer network connects to the grpc receiver
 through the port exposed by the chaincode's Kube `Service` as described in the chaincode 
@@ -70,34 +70,30 @@ launched in the cluster and the chaincode metadata:
 
 To deploy the chaincode, the network script will: 
 
-1.  Read the `connection.json` and `metadata.json` files from the `/chaincode/${TEST_NETWORK_CHAINCODE_NAME` 
+1.  Read the `connection.json` and `metadata.json` files from the `/chaincode/${TEST_NETWORK_CHAINCODE_NAME}` 
     folder, bundling the files into a chaincode tar.gz archive.
 
-
+2.  Install the chaincode archive on a peer in the organization: 
-2.  `kubectl cp` the chaincode archive from the local file system to the organization's persistent volume storage. 
-
-
-3.  Install the chaincode archive on a peer in the organization: 
 ```shell
   export CORE_PEER_ADDRESS='${org}'-peer1:7051
   peer lifecycle chaincode install chaincode/asset-transfer-basic.tgz
 ```
 
 
-4. In typical Fabric operations, the output of the `chaincode install` command includes a generated ID of the 
+3. In typical Fabric operations, the output of the `chaincode install` command includes a generated ID of the 
    chaincode archive printed to standard out.  This ID is manually inspected and transcribed by the 
    network operator when executing subsequent commands with the network peers.  To avoid scraping the 
    output of the installation command, the test network scripts precompute the chaincode ID 
    as the `sha256` checksum of the tar.gz archive. 
 
 
-5. The chaincode docker [image is launched](../kube/org1/org1-cc-asset-transfer-basic.yaml) as a Kubernetes 
+4. The chaincode docker [image is launched using the yaml template](../kube/org1/org1-cc-template.yaml) as a Kubernetes 
    `Deployment` specifying _CHAINCODE_ID=sha-256(archive)_ in the environment and binding a `Service` port 9999 
    within the namespace.  When the network sends messages to the chaincode process, it will use the host URL as 
    defined in the `connection.json`, connecting to the kubernetes `Service` URL and `Deployment`.
    
 
-6.  Finally, the Admin CLI issues a series of peer commands to approve and commit the chaincode for the org: 
+5.  Finally, the Admin CLI issues a series of peer commands to approve and commit the chaincode for the org: 
 
 ```shell
   export CORE_PEER_ADDRESS='${org}'-peer1:7051
@@ -178,7 +174,7 @@ information to the stdout of this process, bundling into a Docker image, and pus
 image to the local development container registry.
 
 1. Add some print statements to assetTransfer.go.  E.g.:
-```java 
+```go
     fmt.Printf("reading asset %s\n", id)
 ```
 

test-network-k8s/docs/CHANNELS.md

@@ -141,7 +141,7 @@ When updating anchor peers, the `./network` script will:
 1.  Transfer the shell scripts from `/scripts/*.sh` into the remote organization's persistent volume.
 2.  Issue a `kubectl exec -c "script-name.sh {args}"` on the org's admin CLI pod.
 
-For non-trivial Fabric administative tasks, this approach of uploading a script into the cluster and then 
+For non-trivial Fabric administrative tasks, this approach of uploading a script into the cluster and then 
 executing in an admin pod works well. 
 
 

test-network-k8s/docs/KUBERNETES.md

@@ -82,7 +82,7 @@ In k8s terms:
 - Blockchain services (nodes, orderers, chaincode, etc.) reside within a single `Namespace`.
 - Each organization maintains a distinct, independent `PersistentVolumeClaim` for TLS certificates,
   local MSP, private data, and transaction ledgers.
-- Smart Contracts rely exclusively on the [Chaincode-as-a-Service](link) and [External Builder](link)
+- Smart Contracts rely exclusively on the [Chaincode-as-a-Service](https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html) and [External Builder](https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html)
   patterns, running in the cluster as Kube `Deployments` with companion `Services`.
 - An HTTP(s) `Ingress` and companion gateway application is required for external access to the blockchain.
 

test-network-k8s/docs/README.md

@@ -37,8 +37,8 @@ _Chaincode-as-a-Service_ running in a shared Kubernetes namespace.
   - [Deploy the ECert CAs](CA.md#deploy-the-organization-ca)
 - [Launching the Test Network](TEST_NETWORK.md)
   - [Registering and Enrolling Identities](CA.md#registering-and-enrolling-identities)
-  - [Assembling Node MSPs](link)
+  - [Assembling Node MSPs](TEST_NETWORK.md#fabric-node-msp-context)
-  - [Deploy Orderers and Peers](link)
+  - [Deploy Orderers and Peers](TEST_NETWORK.md#starting-peers-and-orderers)
 - [Working with Channels](CHANNELS.md)
 - [Working with Chaincode](CHAINCODE.md)
 - [Working with Applications](APPLICATIONS.md)

test-network-k8s/docs/TEST_NETWORK.md

@@ -130,7 +130,7 @@ To trigger the external builder for a chaincode service, set the metadata.json `
 
 Once the local MSP structures for the network nodes have been created, the orderers and peers may be launched in the
 namespace.  System nodes will read base configuration files (orderer.yaml and core.yaml) from the organization
-config folder, made available in Kubernetes as the `fabric-config${org}` config map.
+config folder, made available in Kubernetes as the `${org}-config` config map.
 
 Each orderer and peer creates one `Deployment`, `Pod`, and `Service` in the namespace.  In addition, each org
 defines an `orgN-peerM-config` `ConfigMap` with environment variable overrides replacing the default settings
@@ -148,7 +148,7 @@ export FABRIC_VERSION=2.4.2
 
 cat kube/org0/org0-orderer1.yaml | envsubst | kubectl -n $NS -f -
 cat kube/org0/org0-orderer2.yaml | envsubst | kubectl -n $NS -f -
-cat kube/org0/org0-orderer3.yaml | envsubts | kubectl -n $NS -f -
+cat kube/org0/org0-orderer3.yaml | envsubst | kubectl -n $NS -f -
 
 # Wait for the orderers to completely start before launching the network peer nodes.
 kubectl -n $NS rollout status deploy/org0-orderer1