hyperledger
Multi-org/peer example/test
To make sure all our design really work and also to illustrate to users how a multi-org (and hence, multi-peer) would work we should have a test-case with at least 2 orgs and peers ...
This is a good idea! For solid multi-peer testing the use of the client SDK will make our life much easier.
In such a test we would execute (endorse) a transaction on peer A and check if peer B successfully commits this tx.
We could use the peer CLI for that (https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peerchannel.html#peer-channel-fetch) but this requires polling blocks and parsing them in order to check. Not nice.
Using the fabric client SDK (https://github.com/hyperledger/fabric-sdk-go) one can easily register for events. Eg.
client.RegisterChaincodeEvent(ccID, eventID)
seems the peer CLI indeed provides an event listener, which we can use here (and also remove the sleep command)
--waitForEvent Whether to wait for the event from each peer's deliver filtered service signifying that the 'invoke' transaction has been committed successfully
--waitForEventTimeout duration Time to wait for the event from each peer's deliver filtered service signifying that the 'invoke' transaction has been committed successfully (default 30s)
See here https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peerchaincode.html#peer-chaincode-invoke
relevant pointers of setting up multi-peer/multi-org: https://hyperledger-fabric.readthedocs.io/en/latest/channel_update_tutorial.html
While the peer.sh wrapper tries to handle multi-peer, e.g., in setup as described in PR #144, it was not tested with multi-org/peer, so be warned ...
Note: while in old lifecycle, our peer.sh wrapper logic should have worked with multiple peers and the ercc install&instantiate and the ecc onDemand setup, with the new lifecyle this is not true anymore, e.g., the ercc configuration in channel join would require tighter coordination between multiple peers. So this might require now more explicit additional management commands but also has to be looked at from the perspective of the additional steps necessary for th new key-managment protocols
Another useful feature and test that can be added in this setting is the following:
- 3 peers/orgs, only one of which is the SGX-capable FPC endorser, and only that has the code; the remaining two, however, must still be FPC peers (because of the validation plugins)
- ensure that the LifecycleEndorsement policy is set to majority of orgs (i.e., only the majority can modify the chaincode definition; #313 handles upgrades)
- ensure that the fabric network can go through the approveformyorg step (note: this requires a majority, and requires an org to install a package; so it should be checked whether an empty package or an empty package id is necessary at some org; the Fabric code here suggests that using an empty package id should be viable.)
fabric-sample test-network does already do now in a minimalistical cut multi-peer setup (though no automated test yet)