mirror of
https://github.com/hyperledger/fabric-samples.git
synced 2026-06-17 07:25:10 +00:00
Fix typos and broken links in docs (#712)
Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>
This commit is contained in:
parent
fdcf07dc25
commit
2df09e554d
4 changed files with 6 additions and 6 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue