Asset transfer basic sample was updated for deterministic JSON marshaling:
hyperledger/fabric-samples#486

The corresponding chaincode doc tutorial should also be updated, both the code snippets and a mention about deterministic JSON marshaling:
https://hyperledger-fabric.readthedocs.io/en/latest/chaincode4ade.html

Only the Go chaincode is mentioned in the tutorial, but we can at least mention that the Java and JavaScript samples also demonstrate deterministic JSON marshaling.

See completed RFC at https://github.com/hyperledger/fabric-rfcs/blob/main/text/0000-fabric-gateway.md.

Since payload is included twice in ProposalResponse response messages from peer to client (e.g. GetBlockByNumber), the AbsoluteMaxBytes in channel config must be set at a maximum to half the grpc max message limit (by default 100MB). This should be documented in configtx.yaml and documentation.

The grpc limit will become configurable in #2804

Current documentation has 2 versions of the create a channel tutorial

• Create a channel
  

• Create a channel with the test network
  

The first version describes both how to configure your orderer so that you can use the orderer management APIs or remove the system channel from an existing orderer. Then it describes how to use the osnadmin channel commands to create and manage the channels.

The second version describes only how to use the osnadmin channel commands to create a channel based on the test network which has a single node ordering service without a system channel.

We could consider combining the 2 tutorials or only having the second tutorial, and adding the information from the first tutorial into an ops guide topic instead. That is what this work item is for. Topics to include would be

• describe in detail how to configure an ordering node
  

• considerations around joining additional ordering nodes to the channel
  

• removing the system channel from existing ordering nodes
  

When I tried to install a channel, this error came out:
Error: failed to create deliver client: orderer client failed to connect to orderer1.yzm.com:6051: failed to create new connection: context deadline exceeded.

Folllowing is the command:

安装channel

InstallChannel() {
peer channel create
-o ${ORDERERNODE}
-c ${CHANNEL_NAME}
-f ./channel-artifacts/channel.tx
echo "install channel"
}
where ORDERERNODE = orderer1.yzm.com:6051 and CHANNEL_NAME = mychannel

Lately I find that the container 'orderer1.yzm.com' Exited(2) soon after I started, then I checked the container logs. Here are the details:
panic: Error retrieving consenter of type: pbft

goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc0000c3d90, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore/entry.go:229 +0x546
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).log(0xc000010260, 0x4, 0x1553916, 0x26, 0xc0004a3df8, 0x1, 0x1, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:234 +0x101
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).Panicf(...)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:159
github.com/hyperledger/fabric/common/flogging.(*FabricLogger).Panicf(...)
/opt/gopath/src/github.com/hyperledger/fabric/common/flogging/zap.go:74
github.com/hyperledger/fabric/orderer/common/multichannel.newChainSupport(0xc0000ec000, 0xc000588160, 0xc00058e4e0, 0x16b8420, 0x2140990, 0xc0002167a0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/multichannel/chainsupport.go:69 +0xa13
github.com/hyperledger/fabric/orderer/common/multichannel.(*Registrar).Initialize(0xc0000ec000, 0xc00058e4e0)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/multichannel/registrar.go:168 +0x252
github.com/hyperledger/fabric/orderer/common/server.initializeMultichannelRegistrar(0xc0004f4500, 0xc000214240, 0xc000598b80, 0x0, 0xc000483b00, 0x20e3980, 0xc0002160e0, 0x2, 0x2, 0xc0002160f0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:659 +0x3f7
github.com/hyperledger/fabric/orderer/common/server.Start(0x15309fe, 0x5, 0xc0000bbb00)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:177 +0xb5f
github.com/hyperledger/fabric/orderer/common/server.Main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x208
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20

The Gateway automatically generates the ChaincodeInterest structure to pass to the discovery service to find the optimal set of endorsers. Following the gateway's implementation of this, an extra flag was added to this structure which instructs the discovery service to ignore the chaincode policy if all the state changes are validated by key (SBE) policies. See e5e623d.

In this story, the ChaincodeInterest generation logic in the transaction simulator will be enhanced to support this new 'DisregardNamespacePolicy' flag.

Generate a separate results file that contains the first n differences, ordered by transaction and block number, where n is an integer parameter provided by the user. Command throws an error if no n parameter is provided by the user.

Terminology

• Target peer endpoint (or set of load balanced peers).
• Peer Gateway ("gateway in the peer") versus SDK Gateway ("gateway in the SDK")
• Fabric Gateway SDKs versus Legacy SDKs

Top Priorities (Dave)

• https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html#
• https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

Top priorities (Mark)

• https://hyperledger-fabric.readthedocs.io/en/latest/sdk_chaincode.html#fabric-application-sdks
• https://hyperledger-fabric.readthedocs.io/en/latest/fabric-sdks.html this page could be removed in favor of the prior page.
• https://hyperledger-fabric.readthedocs.io/en/latest/write_first_app.html talks about SDK gateway and submitTransaction() - switch from asset-transfer-basic/application-javascript to asset-transfer-basic/application-gateway-typescript. Mention the two primary patterns 1) delegating endorsement to peer gateway and 2) specifying the endorsing organizations
• https://hyperledger-fabric.readthedocs.io/en/latest/peer_event_services.html#sdk-event-documentation

Top priorities (Andy)

• Add "Gateway" topic next to current Service Discovery architectural topic, cross-link them, and make any updates to "Service Discovery" so that they complement each other well.

Top priorities (Josh with guidance from Andy)

• Key Concepts - Peer topic. Add a peer gateway section in or around the "Applications and Peers" section to introduce the gateway key concepts. Mention the two primary patterns 1) delegating endorsement to peer gateway and 2) specifying the endorsing organizations.
• https://hyperledger-fabric.readthedocs.io/en/latest/peers/peers.html#applications-and-peers -
• https://hyperledger-fabric.readthedocs.io/en/latest/peers/peers.html#peers-and-organizations
• https://hyperledger-fabric.readthedocs.io/en/latest/peers/peers.html#phase-1-proposal

Top priorities (Chris with guidance from Andy and Mark)

• updating existing applications to use new SDKs

Key Concepts - Private data (Andy)

• Mention the different gateway behavior when working with private data collections.
• https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#transaction-flow-with-private-data

Other Key Concept topics (Josh)

• There are minor references to application/peer flow in these topics. At each occurrence mention 'target' peer distributes the request to endorsing peers, and when using 'legacy SDKs' it is the application/SDK responsibility.
• https://hyperledger-fabric.readthedocs.io/en/latest/network/network.html#using-an-application-on-the-channel
• https://hyperledger-fabric.readthedocs.io/en/latest/orderer/ordering_service.html#phase-one-proposal
• https://hyperledger-fabric.readthedocs.io/en/latest/orderer/ordering_service.html#phase-two-ordering-and-packaging-transactions-into-blocks

Tutorials (Josh)

• Each of these tutorials utilize peer CLI "peer chaincode invoke" with --peerAddresses. At the first occurrence within each tutorial simply state that CLI does not use gateway and you must target all the endorsing peers.
• https://hyperledger-fabric.readthedocs.io/en/latest/test_network.html
• https://hyperledger-fabric.readthedocs.io/en/latest/deploy_chaincode.html
• https://hyperledger-fabric.readthedocs.io/en/latest/secured_asset_transfer/secured_private_asset_transfer_tutorial.html

FAQ - minor edits required (Dave)

• https://hyperledger-fabric.readthedocs.io/en/latest/Fabric-FAQ.html#endorsement
• https://hyperledger-fabric.readthedocs.io/en/latest/Fabric-FAQ.html#application-side-programming-model

Developing Applications and Commercial Paper tutorial (Andy/Mark/Matthew/James)

• These topics discuss legacy SDK approach in detail. Developing Applications needs an entire overhaul with peer gateway highlighted. Will be tracked in #2983.
• https://hyperledger-fabric.readthedocs.io/en/latest/developapps/application.html
• https://hyperledger-fabric.readthedocs.io/en/latest/developapps/connectionprofile.html
• https://hyperledger-fabric.readthedocs.io/en/latest/developapps/connectionoptions.html
• https://hyperledger-fabric.readthedocs.io/en/latest/developapps/wallet.html
• https://hyperledger-fabric.readthedocs.io/en/latest/developapps/gateway.html
• https://hyperledger-fabric.readthedocs.io/en/latest/tutorial/commercial_paper.html

Integration test often fails in CI when using Go 1.16.7 at https://github.com/hyperledger/fabric/blob/main/integration/raft/config_test.go#L165.
The issue was not seen on prior Go version 1.15.7.
I cannot reproduce the issue in my environment on Go 1.16.7, it only appears in the Azure Pipeline execution.

The test expects orderer process to panic (and it does), however the test framework never receives notification that orderer process exited and eventually times out.

One (of many) occurrence here:
https://dev.azure.com/Hyperledger/Fabric/_build/results?buildId=39833&view=logs&jobId=4697389f-44ab-596f-b978-8083358e29e9&j=ea1ac65f-4899-54ff-1ca2-4326ac9b04bd&t=e554e2e7-1dcb-559d-af46-177f3e7010f2&s=435370a6-f89a-5869-4d11-90398ab6993a

2021-08-25T23:45:38.2465936Z [e][OrdererOrg.orderer] 2021-08-25 23:44:38.080 UTC 0020 INFO [orderer.commmon.multichannel] initSystemChannel -> Starting system channel 'systemchannel' with genesis block hash 1566701a79b2298c46b16b2cc6453dc0cee41e1dcfd755f9c45155a5016465bd and orderer type etcdraft
2021-08-25T23:45:38.2467041Z [e][OrdererOrg.orderer] 2021-08-25 23:44:38.080 UTC 0021 INFO [orderer.consensus.etcdraft] Start -> Starting Raft node channel=systemchannel node=1
2021-08-25T23:45:38.2468053Z [e][OrdererOrg.orderer] 2021-08-25 23:44:38.080 UTC 0022 INFO [orderer.common.cluster] Configure -> Entering, channel: systemchannel, nodes: []
2021-08-25T23:45:38.2468967Z [e][OrdererOrg.orderer] 2021-08-25 23:44:38.080 UTC 0023 INFO [orderer.common.cluster] Configure -> Exiting
2021-08-25T23:45:38.2469934Z [e][OrdererOrg.orderer] 2021-08-25 23:44:38.080 UTC 0024 INFO [orderer.consensus.etcdraft] start -> Starting raft node as part of a new channel channel=systemchannel node=1
2021-08-25T23:45:38.2470723Z [e][OrdererOrg.orderer] panic: election tick must be greater than heartbeat tick
2021-08-25T23:45:38.2471229Z [e][OrdererOrg.orderer] 
2021-08-25T23:45:38.2471700Z [e][OrdererOrg.orderer] goroutine 1 [running]:
2021-08-25T23:45:38.2473407Z [e][OrdererOrg.orderer] go.etcd.io/etcd/raft.newRaft(0xc00037e2c0, 0xa4506ceb90befffa)
2021-08-25T23:45:38.2474253Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/vendor/go.etcd.io/etcd/raft/raft.go:326 +0xef1
2021-08-25T23:45:38.2475033Z [e][OrdererOrg.orderer] go.etcd.io/etcd/raft.StartNode(0xc00037e2c0, 0xc0003ce3c0, 0x1, 0x1, 0xa3c481f234d6c922, 0x40d05f09435f9c79)
2021-08-25T23:45:38.2475728Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/vendor/go.etcd.io/etcd/raft/node.go:201 +0x45
2021-08-25T23:45:38.2476564Z [e][OrdererOrg.orderer] github.com/hyperledger/fabric/orderer/consensus/etcdraft.(*node).start(0xc00037e370, 0x1)
2021-08-25T23:45:38.2477315Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/orderer/consensus/etcdraft/node.go:73 +0x297
2021-08-25T23:45:38.2478006Z [e][OrdererOrg.orderer] github.com/hyperledger/fabric/orderer/consensus/etcdraft.(*Chain).Start(0xc00022c840)
2021-08-25T23:45:38.2478676Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/orderer/consensus/etcdraft/chain.go:362 +0x1b5
2021-08-25T23:45:38.2479362Z [e][OrdererOrg.orderer] github.com/hyperledger/fabric/orderer/common/multichannel.(*ChainSupport).start(...)
2021-08-25T23:45:38.2480034Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/orderer/common/multichannel/chainsupport.go:120
2021-08-25T23:45:38.2480759Z [e][OrdererOrg.orderer] github.com/hyperledger/fabric/orderer/common/multichannel.(*Registrar).startChannels(0xc000459600)
2021-08-25T23:45:38.2481459Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/orderer/common/multichannel/registrar.go:177 +0xb5
2021-08-25T23:45:38.2482209Z [e][OrdererOrg.orderer] github.com/hyperledger/fabric/orderer/common/multichannel.(*Registrar).Initialize(0xc000459600, 0xc000474cc0)
2021-08-25T23:45:38.2482928Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/orderer/common/multichannel/registrar.go:147 +0x8e
2021-08-25T23:45:38.2483850Z [e][OrdererOrg.orderer] github.com/hyperledger/fabric/orderer/common/server.initializeMultichannelRegistrar(0xc00015a640, 0xc000452900, 0xc0000a4e00, 0x0, 0x0, 0xc000081c00, 0x398, 0x399, 0xc0000fe600, 0xf1, ...)
2021-08-25T23:45:38.2484655Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/orderer/common/server/main.go:828 +0x485
2021-08-25T23:45:38.2485264Z [e][OrdererOrg.orderer] github.com/hyperledger/fabric/orderer/common/server.Main()
2021-08-25T23:45:38.2485903Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/orderer/common/server/main.go:245 +0x10ef
2021-08-25T23:45:38.2486414Z [e][OrdererOrg.orderer] main.main()
2021-08-25T23:45:38.2486962Z [e][OrdererOrg.orderer] 	/home/vsts/work/1/fabric/cmd/orderer/main.go:15 +0x25
2021-08-25T23:45:38.2487173Z 
2021-08-25T23:45:38.2487518Z ------------------------------
2021-08-25T23:45:38.2487938Z • Failure [60.342 seconds]
2021-08-25T23:45:38.2488577Z EndToEnd reconfiguration and onboarding Invalid Raft config metadata [It] refuses to start orderer or rejects config update 
2021-08-25T23:45:38.2489211Z /home/vsts/work/1/fabric/integration/raft/config_test.go:146
2021-08-25T23:45:38.2489391Z 
2021-08-25T23:45:38.2489716Z   Timed out after 60.001s.
2021-08-25T23:45:38.2489958Z   Expected
2021-08-25T23:45:38.2490358Z       <<-chan error | len:1, cap:1>: 0xc000a84840
2021-08-25T23:45:38.2490774Z   to receive something.
2021-08-25T23:45:38.2490962Z 
2021-08-25T23:45:38.2491216Z   /home/vsts/work/1/fabric/integration/raft/config_test.go:165
2021-08-25T23:45:38.2491675Z ------------------------------
2021-08-25T23:53:49.0284685Z ••••••••••••••••••••
2021-08-25T23:53:49.0306463Z 
2021-08-25T23:53:49.0307909Z Summarizing 1 Failure:
2021-08-25T23:53:49.0308362Z 
2021-08-25T23:53:49.0309455Z [Fail] EndToEnd reconfiguration and onboarding Invalid Raft config metadata [It] refuses to start orderer or rejects config update 
2021-08-25T23:53:49.0310630Z /home/vsts/work/1/fabric/integration/raft/config_test.go:165

Generate a list of differences between the private data in a separate json output file when running the compare command.

This documentation Epic serves as an umbrella that captures the Fabric documentation priorities. See the included links for the actual work items.

Goal is to create a ledger troubleshooting utility that can identify differences between two snapshots from different peers. Utility will take two snapshots at the same height from different peers as input. Utility will then compare each key / value pair between the snapshots. Tool will output the key / value pairs that are dissimilar between the two snapshots.

New "peer node unjoin" CLI command to unjoin a peer from a channel.
Peer must be down when command is run.
For more details see https://jira.hyperledger.org/browse/FAB-11334

Add extra integration tests to the gateway suite to verify the automatic generation of the ChaincodeInterest structure is working as expected. In particular the following areas should have integration test coverage:

• Submitting transactions that modify an SBE state.
• Submitting transactions that modify a private data collection.
• Submitting transactions involving chaincode to chaincode calls.

All of these scenarios affect the ChaincodeInterest structure which, in turn, affects which organizations are required to endorse.

GOAL
Identify transactions that have caused divergent state.

INPUT
Set of keys in question (JSON output from state comparison utility)

APPROACH
Traverse the block store on each peer (separately) to identify and extract transactions that wrote mismatched keys

OUTPUT
Set of transactions that wrote the keys (in human readable format)
All tx validation codes from the respective blocks
Block commit hashes from the respective blocks (available on channels created in v1.4.2 and later)

Ability to filter ledger channel state comparison by chaincode namespace. This can be achieved with addition of a new command flag for the namespace.

Version 1.3

There are two chain codes (a and b) in the service channel. The service needs to call a, and a calls b internally.

The process was called twice in a row, and two transactions occurred in the same block. The one write set is as follows:

7915734a54a1237c9338fec28e82d72daec9d8a8d4384077a1994ca5bdecc5ba
71784071997b2ffcad95d29de0a1fa4447543aad883898ac01a637961937b8f0

key:55F909BED11F60F8F96B03E615BAF035D6DF7C70,is_delete:false,value:{"id":"55F909BED11F60F8F96B03E615BAF035D6DF7C70","name":"","nonce":128,"balance":211,"remark":"","delFlag":false,"ex1":"","ex2":"","ex3":"","ex4":"","ex5":"","ex6":"","ex7":"","ex8":"","ex9":"","ex10":""} key:preTransAccount,is_delete:false,value:{"id":"preTransAccount","name":"preTransAccount","nonce":56,"balance":10489,"remark":"","delFlag":false,"ex1":"","ex2":"","ex3":"","ex4":"","ex5":"","ex6":"","ex7":"","ex8":"","ex9":"1","ex10":""} key:**xxr_reward_prexxr_reward_10068**,is_delete:false,value:{"type":"xxr_reward_pre","from":"55F909BED11F60F8F96B03E615BAF035D6DF7C70","nonce":128,"to":"preTransAccount","value":7,"remark":"","delFlag":false} key:xxr_reward_pre55F909BED11F60F8F96B03E615BAF035D6DF7C70128preTransAccount,is_delete:false,value:{"type":"xxr_reward_pre","from":"55F909BED11F60F8F96B03E615BAF035D6DF7C70","to":"preTransAccount","nonce":128,"value":7,"remark":""}

Note the key: xxr_reward_prexxr_reward_10068.
The write set shows that the data has been generated, but it cannot be queried.

Query the peer running log to find:
Block [527] Transaction index [1] TxId [71784071997b2ffcad95d29de0a1fa4447543aad883898ac01a637961937b8f0] marked as invalid by state validator. Reason code [MVCC_READ_CONFLICT]

How to understand this phenomenon?

See background discussion at https://jira.hyperledger.org/browse/FAB-5097.

See agreed upon RFC at https://github.com/hyperledger/fabric-rfcs/blob/main/text/0000-private_data_purge.md.

Hi there, I'm new with fabric 1.4, I try to understand how can I build an oracle in golang for smart contract, have you some good resources, articles, posts, or practical exemple to start with? thanks

When a gateway call to a peer function returns an error, the error does not get returned to the gateway client, only a generic gateway error message gets returned to client. Clients will therefore not know the cause of the error or how to fix.

For example, my error was that I was calling the wrong chaincode function, but the application client only received the generic error:
"Error: 10 ABORTED: failed to endorse transaction"
It did not receive the underlying error message from the endorser, which after adding debug code I can see is "error 500, Function put not found in contract SmartContract".

The reason is that rpcError() is used for gateway error handling, the error details that are passed in and set in status.WithDetails() do not get returned in the ultimate status.Err() error message, see line at:
https://github.com/hyperledger/fabric/blob/main/internal/pkg/gateway/apiutils.go#L77

Thanks @andrew-coleman for adding the integration test.

One more point - I am not sure what was the motivation but it appears that we also allow the implicit collection policy to be configured via channel config.

I feel that moving the existing code in a separate function and invoking that function from both the existing code and your code may allow to keep this important logic at one place.

Originally posted by @manish-sethi in #2784 (comment)

For background see https://jira.hyperledger.org/browse/FAB-5097

I have noticed a strange bug with Hyperledger Fabric's latest release 2.3

The organization's cryptogen files have user limit check, but this check doesn't work exactly.

# "Users" # --------------------------------------------------------------------------- # Count: The number of user accounts _in addition_ to Admin # --------------------------------------------------------------------------- Users: Count: 2

Only 2 additional users can be in this organization. But I have created more than 10 users.

This is a test of the invalid issue feature.

Currently the gateway's Evaluate() method will use discovery to select a peer (with highest block height) in order to evaluate the proposal unless overridden by the target_organizations property.

If transient data is included in the proposal, this could result in sensitive information being leaked to another org's peer.

This story will ensure that queries involving transient data are only sent to a peer in the gateway's org unless specifically overridden by the target_organizations property.

Pruning old blocks from peer to alleviate concerns around long term storage growth.

The snapshot feature delivered in v2.3 enables organizations to compare ledgers on a channel and come to agreement around logical "checkpoints". These checkpointed snapshots can be saved off and used as a starting point for new peers so that they don't have to process all blocks since the genesis block. With the concept of snapshots and checkpoints established, it is feasible to prune blocks prior to the checkpointed ledger height.

This issue serves as a placeholder until a pruning RFC becomes available.

The Fabric Operations Guide describes a process by which a Fabric network administrator may install an external builder to support the lifecycle of external chaincode service endpoints. This involves updating the peer's config file with the location of the external builder, and installing the build, detect, and release binaries on the peer file system.

The documentation guide provides a reference sample of external builder scripts (bash), but this path is difficult to realize in orchestrated clusters (e.g. Kubernetes.) A couple of pain points include:

• The sample bash scripts rely on jq for manipulating the metadata and connection json files, but jq is not available on the hyperledger/fabric-peer image.
• Deploying custom scripts and files into the peer image is possible using a combination of Kubernetes configmaps, init containers, or volume shares, but the process adds an additional, tedious configuration step for the network administrator.

The issues outlined above add just enough structural friction to delay or defer the migration to chaincode-as-a-service (CCaaS) deployments. Let's make this trivial for end-users to update to the new pattern by:

1. Including reference chaincode-as-a-service builder binaries into the hyperledger/fabric-peer Docker image.

or

2. Include a CCaaS build pipelines into the peer's Golang runtime.

With option (1), the network will enable the default CCaaS builder by modifying core.yaml, referencing a known (documented) location for the system builder. E.g.:

externalBuilders:
  - name: fabric-ccs-builder
    path: /usr/local
    propagateEnvironment:
      - HOME
      - CORE_PEER_ID
      - CORE_PEER_LOCALMSPID

The fabric-peer image, in turn, will need to be supplemented with fabric-ccs-builder (or equivalent) binaries on the docker image. In the configuration above, the image file system includes:

- usr
    +- local
        +- bin
            +- peer 
            +- build 
            +- detect 
            +- release 

In option (2) above, instead of distributing external binaries with the hyperledger/fabric-peer image, the peer binary will be supplemented with logic suitable for emulating the build, detect, release lifecycle without exec-ing a new process. With this pattern, the network administrator may register the default builder by specifying an attribute in the externalBuilders configuration stanza, e.g.:

  - name: fabric-ccs-builder
    type: ccsas
    propagateEnvironment:
      - HOME
      - CORE_PEER_ID
      - CORE_PEER_LOCALMSPID

With the latter configuration, when the peer detects an external builder with the ccaas type, the routines internally bypass the fork/exec, invoking native Golang routines to manipulate the chaincode descriptors.

Choose one of these approaches (or a third...) and bundle an external builder into the base fabric image. This will be a valuable time-saver and convenience for running chaincode-as-a-service in Fabric networks.

See history at https://jira.hyperledger.org/browse/FAB-18102

My orderer stopped due to the following error：

When I restarted the orderer, I got a new error
Error creating consenter: failed to restore persisted raft data: failed to create or read WAL: failed to open WAL: fileutil: file already locked。
What should I do to restart the orderer？

This is from https://stackoverflow.com/questions/68635379/hyperledger-fabric-adding-new-members-to-channel-with-private-data-can-i-do/68643959#68643959 with the description being:
"""
As of now, every collection configuration is an explicit policy, so you need to perform an operation for each collection.

However, the design / architecture doesn't restrict the policy to be an explicit one, and is flexible enough to accommodate a dynamic policy that is referenced and you can then update just the reference once instead of updating each collection.

Sadly, this isn't implemented yet. If you open a JIRA / Github issue / send an email in the mailing list then maybe it will be implemented at some point in the future.

It shouldn't be too hard to implement. All we need is to:

Stick a policy in the channel config tree.
Extend the CollectionPolicyConfig with another option of a policy reference and use the aforementioned reference.

"""

solution：
vim go.mod
module github.com/hyperledger/fabric/v2
go 1.14
require (...)

When the orderer section of the deployment guide is merged, one of the purposes of this doc: https://hyperledger-fabric.readthedocs.io/en/release-2.2/raft_configuration.html

Will be superseded by it.

This Raft configuration doc does a few things other than talk about initial orderer parameters (which is the limit of the scope of the deployment guide), however. It also talks about:

• Channel configuration parameters relevant to the ordering service.
  

• Adding a new node to an ordering service.
  

• Certificate rotation.
  

• Hidden parameters.
  

I would suggest that, long term, the process for adding a node to an ordering service should be its own tutorial, and that likewise rotating certificates is worth of a broader operations guide topic talking about more than just ordering nodes.

The hidden parameters and channel config parameters would seem to belong in a reference topic.

See https://jira.hyperledger.org/browse/FAB-18420 and #2800.

While there is some scattered guidance for dealing with certificate expirations throughout the Fabric docs, we need to pull the information all together and make it more comprehensive so that users have a complete view of the various certificates in Fabric environments and step-by-step guidance for dealing with expired certificates (e.g. user vs node vs TLS certificate expirations).

I am looking for how can I build docker images for fabric components like peer, orderers, ccenv etc for arm based architecture. I pulled fabric, fabric-ca and fabric-baseimage and make changes in respected Dockerfile but while running make getting below error. Please help me in that.

Docker: building couchdb image
docker build   -t hyperledger/fabric-couchdb -f images/couchdb/Dockerfile images/couchdb
[+] Building 6.8s (11/17)                                                                                                
 => [internal] load build definition from Dockerfile                                                                0.0s
 => => transferring dockerfile: 37B                                                                                 0.0s
 => [internal] load .dockerignore                                                                                   0.0s
 => => transferring context: 2B                                                                                     0.0s
 => [internal] load metadata for docker.io/arm64v8/debian:buster                                                    3.4s
 => [auth] arm64v8/debian:pull token for registry-1.docker.io                                                       0.0s
 => [internal] load build context                                                                                   0.0s
 => => transferring context: 151B                                                                                   0.0s
 => [ 1/12] FROM docker.io/arm64v8/debian:buster@sha256:b4cf9a9f5266cd9e75a5648238831b88ed4d124567f2e3a5beca0d9dab  0.0s
 => CACHED [ 2/12] RUN groupadd -g 5984 -r couchdb && useradd -u 5984 -d /opt/couchdb -g couchdb couchdb            0.0s
 => CACHED [ 3/12] RUN apt-get update -y && apt-get install -y --no-install-recommends     ca-certificates     cur  0.0s
 => CACHED [ 4/12] RUN set -ex;   apt-get update;  apt-get install -y --no-install-recommends wget;  rm -rf /var/l  0.0s
 => CACHED [ 5/12] RUN set -xe     && for key in 15DD4F3B8AACA54740EB78C7B7B7C53943ECCEE1   1CFBFA43C19B6DF4A0CA39  0.0s
 => ERROR [ 6/12] RUN buildDeps='     apt-transport-https     gcc     g++     erlang-dev     libcurl4-openssl-dev   3.4s
------                                                                                                                   
 > [ 6/12] RUN buildDeps='     apt-transport-https     gcc     g++     erlang-dev     libcurl4-openssl-dev     libicu-dev     libmozjs185-dev     make   '  && apt-get update -y -qq && apt-get install -y --no-install-recommends $buildDeps  && cd /usr/src && mkdir couchdb  && curl -fSL https://archive.apache.org/dist/couchdb/source/2.3.1/apache-couchdb-2.3.1.tar.gz -o couchdb.tar.gz  && curl -fSL https://archive.apache.org/dist/couchdb/source/2.3.1/apache-couchdb-2.3.1.tar.gz.asc -o couchdb.tar.gz.asc  && gpg --batch --verify couchdb.tar.gz.asc couchdb.tar.gz  && tar -xzf couchdb.tar.gz -C couchdb --strip-components=1  && cd couchdb  && ./configure --disable-docs  && make release  && mv /usr/src/couchdb/rel/couchdb /opt/  && apt-get purge -y --auto-remove $buildDeps  && rm -rf /var/lib/apt/lists/* /usr/src/couchdb*  && mkdir /opt/couchdb/data  && chown -R couchdb:couchdb /opt/couchdb:
#10 2.919 Reading package lists...
#10 3.242 Building dependency tree...
#10 3.303 Reading state information...
#10 3.346 E: Unable to locate package libmozjs185-dev
------
executor failed running [/bin/sh -c buildDeps='     apt-transport-https     gcc     g++     erlang-dev     libcurl4-openssl-dev     libicu-dev     libmozjs185-dev     make   '  && apt-get update -y -qq && apt-get install -y --no-install-recommends $buildDeps  && cd /usr/src && mkdir couchdb  && curl -fSL https://archive.apache.org/dist/couchdb/source/$COUCHDB_VERSION/apache-couchdb-$COUCHDB_VERSION.tar.gz -o couchdb.tar.gz  && curl -fSL https://archive.apache.org/dist/couchdb/source/$COUCHDB_VERSION/apache-couchdb-$COUCHDB_VERSION.tar.gz.asc -o couchdb.tar.gz.asc  && gpg --batch --verify couchdb.tar.gz.asc couchdb.tar.gz  && tar -xzf couchdb.tar.gz -C couchdb --strip-components=1  && cd couchdb  && ./configure --disable-docs  && make release  && mv /usr/src/couchdb/rel/couchdb /opt/  && apt-get purge -y --auto-remove $buildDeps  && rm -rf /var/lib/apt/lists/* /usr/src/couchdb*  && mkdir /opt/couchdb/data  && chown -R couchdb:couchdb /opt/couchdb]: exit code: 100
make: *** [build/image/couchdb/.arm64-0.4.20] Error 1

when i use external builder to install a chaincode. the install is successed,but when i call invoke func ,the fabric return:
could not launch chaincode business3-golang-0-0-1:55c567d3eb1e5a35d12d9243cc782cfdd9fa226fc1e6250c4070ae4c47e0817e: chaincode registration failed: connection to business3-golang-0-0-1:55c567d3eb1e5a35d12d9243cc782cfdd9fa226fc1e6250c4070ae4c47e0817e terminated.

See details and occurrences in https://jira.hyperledger.org/browse/FAB-18506

Hi @sykesm , @jyellick

I am developing a Fabric application, and I am facing the issue where gateway is not able to get the network

366 | await gateway.connect(ccp, gatewayOpts);

367 | const network = await gateway.getNetwork(channelName);
| ^
368 | const contract = network.getContract(chaincodeName);
In Line number 367 I am facing an error

Following is the error :-

2021-07-24T13:39:03.866Z - error: [ServiceEndpoint]: Error: Failed to connect before the deadline on Endorser- name: peer0.org1.example.com, url:grpcs://localhost:7051, connected:false, connectAttempted:true
2021-07-24T13:39:03.867Z - error: [ServiceEndpoint]: waitForReady - Failed to connect to remote gRPC server peer0.org1.example.com url:grpcs://localhost:7051 timeout:3000
2021-07-24T13:39:03.893Z - info: [NetworkConfig]: buildPeer - Unable to connect to the endorser peer0.org1.example.com due to Error: Failed to connect before the deadline on Endorser- name: peer0.org1.example.com, url:grpcs://localhost:7051, connected:false, connectAttempted:true
at checkState (/home/user/Documents/Learnings/aries-learning/aries-javascript/aries-framework-javascript/node_modules/@grpc/grpc-js/src/client.ts:169:18)
at Timeout._onTimeout (/home/user/Documents/Learnings/aries-learning/aries-javascript/aries-framework-javascript/node_modules/@grpc/grpc-js/src/channel.ts:579:9)
at listOnTimeout (internal/timers.js:554:17)
at processTimers (internal/timers.js:497:7) {
connectFailed: true
}
2021-07-24T13:39:07.452Z - error: [ServiceEndpoint]: Error: Failed to connect before the deadline on Discoverer- name: peer0.org1.example.com, url:grpcs://localhost:7051, connected:false, connectAttempted:true
2021-07-24T13:39:07.452Z - error: [ServiceEndpoint]: waitForReady - Failed to connect to remote gRPC server peer0.org1.example.com url:grpcs://localhost:7051 timeout:3000
2021-07-24T13:39:07.453Z - error: [ServiceEndpoint]: ServiceEndpoint grpcs://localhost:7051 reset connection failed :: Error: Failed to connect before the deadline on Discoverer- name: peer0.org1.example.com, url:grpcs://localhost:7051, connected:false, connectAttempted:true
2021-07-24T13:39:07.453Z - error: [DiscoveryService]: send[mychannel] - no discovery results

I had asked this question on discussion forum, but no one answered it?

Can anyone help me in resolving this?
Thanks

grpc max message size is hardcoded to 100MB for both grpc clients and servers, in both peer and orderer.

Max messages size should be configurable in peer core.yaml and orderer.yaml (right next to the keepalive config options).

To see where max message size is set in the code, grep for DefaultMaxRecvMsgSize and DefaultMaxSendMsgSize.

More history can be found in https://jira.hyperledger.org/browse/FAB-6461