diff --git a/asset-transfer-basic/rest-api-typescript/README.md b/asset-transfer-basic/rest-api-typescript/README.md index ab928154..f5e0953a 100644 --- a/asset-transfer-basic/rest-api-typescript/README.md +++ b/asset-transfer-basic/rest-api-typescript/README.md @@ -58,7 +58,7 @@ The `202 ACCEPTED` response includes a `jobId` which can be used with the `/api/ Jobs are not used to get assets, because evaluating transactions is typically much faster. Related files: -- [src/asset.router.ts](src/asset.router.ts) +- [src/assets.router.ts](src/assets.router.ts) Defines the main `/api/assets` endpoint. - [src/fabric.ts](src/fabric.ts) All the sample code which interacts with the Fabric network via the Fabric SDK. @@ -66,7 +66,7 @@ Related files: Defines the `/api/jobs` endpoint for getting job status. - [src/jobs.ts](src/jobs.ts) Job queue implementation details. -- [src/transactions.router.ts]() +- [src/transactions.router.ts](src/transactions.router.ts) Defines the `/api/transactions` endpoint for getting transaction status. **Note:** If you are not specifically interested in REST APIs, you should only need to look at the files in the [Fabric network connections](#fabric-network-connections) and [Error handling](#error-handling) sections above. diff --git a/test-network-k8s/docs/CA.md b/test-network-k8s/docs/CA.md index 48624536..f10302ef 100644 --- a/test-network-k8s/docs/CA.md +++ b/test-network-k8s/docs/CA.md @@ -72,7 +72,7 @@ simplified, but realistic CA deployment illustrating key touch points with Kuber ### Future Enhancements: -- **_Bring your own Certificates_** : It would be nice to boostrap the network using a single, top-level signing authority, +- **_Bring your own Certificates_** : It would be nice to bootstrap the network using a single, top-level signing authority, rather than generating self-signed certificates when the system is bootstrapped. Ideally this will be realized by introducing an [Intermediate CA](https://hyperledger-fabric-ca.readthedocs.io/en/latest/deployguide/ca-deploy-topology.html#when-would-i-want-an-intermediate-ca) and/or alternate signing chains backed by formal (e.g. letsencrypt, Thawte, Verisign, etc.) certificate authorities. diff --git a/test-network-k8s/docs/CHANNELS.md b/test-network-k8s/docs/CHANNELS.md index b72e5d92..cfc23980 100644 --- a/test-network-k8s/docs/CHANNELS.md +++ b/test-network-k8s/docs/CHANNELS.md @@ -33,7 +33,7 @@ In order to construct a Fabric channel, the following steps must be performed: 4. Network orderers are joined to the channel using the channel participation API. -5. Network peers are joioned to the channel. +5. Network peers are joined to the channel. ## Aggregating the Channel MSP diff --git a/test-network-k8s/docs/HIGH_AVAILABILITY.md b/test-network-k8s/docs/HIGH_AVAILABILITY.md index 585f09cc..1725e4bc 100644 --- a/test-network-k8s/docs/HIGH_AVAILABILITY.md +++ b/test-network-k8s/docs/HIGH_AVAILABILITY.md @@ -4,7 +4,7 @@ The peers have been configured so they implemented a essential failover/high-ava Two important notes: -1. The word 'gateway' in the k8s definitions is being used in a generic way. It is not tied to the concept of the 'Fabric Gateway' component. However using the 'Fabric-Gateway' with the udpated SDKs, make connecting to Fabric even easier. There is a single connection, that can easily be handled with core k8s abilities. Attempting the approach described below with the older SDKs is not recommended. +1. The word 'gateway' in the k8s definitions is being used in a generic way. It is not tied to the concept of the 'Fabric Gateway' component. However using the 'Fabric-Gateway' with the updated SDKs, make connecting to Fabric even easier. There is a single connection, that can easily be handled with core k8s abilities. Attempting the approach described below with the older SDKs is not recommended. 2. Long Lived gRPC connections. Remember that the connections between components in Fabric are long-lived gRPC connections. From a client application's perspective that means the connection will be load-balanced when initially connected, but unless the connection breaks, it will not be 're-load-balanced'. It's important to keep this in mind. ## Peer Gateway Services @@ -39,7 +39,7 @@ The selector is `org: org2` that is defined in the specification of the Peer's D ``` ## Kube Proxy Configuration -The proxy configuration is set to be `ipvs`. This gives a lot more scope for different load balancing algorthms. +The proxy configuration is set to be `ipvs`. This gives a lot more scope for different load balancing algorithms. "Round Robin" is the default configuration (as used in this test network). For more information check this [deep dive](https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive) on the Kubernetes blog. For this KIND cluster, this is configured by updating the cluster configuration, add the following yaml.