Re: Adding a peer node when no genesis block orderer exist in the channel #fabric-orderer #raft #hyperledger-fabric

Gari Singh <garis@...>

The desired solution for this is to allow peers to join channels starting from the latest config block rather than requiring starting from the genesis block.
The checkpoint/archive feature will also help here as well as a peer will be able to start from the latest state and checkpoint as well.

In the interim, we did look at modifying the JoinChannel API to allow passing in the "orderer override" information but at the time deemed it a bit too invasive and did not want to invest in hacking the current JoinChannel API implementation as we plan to move away from the system chaincode approach currently being used. Additionally, you actually need to persist the override information in the case where you decide to rebuild the ledger for a given channel. Simply passing overrides as part of the API is not enough; we'd also have to persist this override information as well.

Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499

-----fabric@... wrote: -----
To: fabric@...
From: chintanr97@...
Sent by: fabric@...
Date: 05/19/2020 12:37AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Adding a peer node when no genesis block orderer exist in the channel #fabric-orderer #raft #hyperledger-fabric

@Yacov, I would like to highlight that why aren't we making using of peer CLI command for this? I mean to say that in "peer channel join" command we have an option of specifying the orderer endpoint, right? We should just extend that to be used in the scenario where peer cannot pull blocks from genesis block orderers. Specifying "-o" argument should make the peer pull channel blocks from the specified endpoint instead of looking into config block.

You can run the peer channel join command like follows:
peer channel join -b mychannel.block -o --tls --cafile <ordererTLSCAFile>

The benefit would be:
The change in core.yaml is permanent like you explained on my JIRA. This feature would be dynamic in nature.
Already running peers could join newer channels dynamically.
Currently, I tried implementing above feature but peer node does respect the "-o" argument (and yet we have it in the "peer" binary commands). If we are using it in other operations like "invoke" then we should allow this command to run parallel to that, giving a more dynamic nature, instead of making using of core.yaml.

Please let me know your thoughts on this.

Join to automatically receive all group messages.