Fix typos and broken links in docs (#712)

Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>
This commit is contained in:
Tatsuya Sato 2022-04-18 22:36:49 +09:00 committed by GitHub
parent fdcf07dc25
commit 2df09e554d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 6 additions and 6 deletions

View file

@ -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.

View file

@ -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.

View file

@ -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

View file

@ -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.