In fabric-network/docker-based-syschannel
Which uses the default implicit majority endorsement policy
This will set it to all 3 orgs required as the default
to set it to an explicit majority endorsement policy
(TODO: Is there are way to return it to an implicit majority policy ?)
Note it is important to remember your current sequence number set by ccs for other activities
this expects that you have already brought the main network up, created a channel and deployed chaincode. Make sure you know your current sequence number as well as your deployed employment policy
To add Org4 to the environment and join the peers to the channel
To deploy chaincode to those peers you need the current chaincode definition sequence and the endorsement policy. So for example if you haven't changed the endorsement policy yet then
should suffice. If you have changed the endorsement policy eg AND('Org1MSP.member','Org2MSP.member','Org3MSP.member') which is the inbuilt default for ./network.sh changeCCEndorsement then you might need
Once org4 is up you should use the org4.sh script to change endorsement policies rather than network.sh, eg
This will set it to all 4 orgs required as the default
to give an explicit majority for the 4 orgs
Make sure you increment the sequence number by 1. As the scripts are not atomic you can leave yourself in a partial state where some actions have succeeded and some have not.
You can use either ./network.sh down
or ./org4.sh down
to bring the network down.
Make sure you are using Node 14 or higher LTS release In client
keyword | values | default | description |
---|---|---|---|
LOG_LEVEL | 'Failure','All','Failure&Success' | Failure | Set the log output |
ORGS | identities for each org | ||
ORG | the org this client is running as | ||
MAX_TRANSACTION_COUNT | number | 30 | |
PEER_ENDPOINT | external address of gatewat peer to connect to | ||
CHANNEL_NAME | string | 'mychannel' | Name of the channel used |
CHAINCODE_NAME | string | 'basic' | Name of the chaincode deployed |
GATEWAY_PEER | used for ssl target name override | ||
MAXLIMIT | number | 500 | max time in MS to wait before checking backlog has reduced |
MINLIMIT | number | 50 | min time in MS to wait before checking backlog has reduced |
GRPCSLEEPMAX | number | 1000 | max sleep between each waitForReady |
GRPCSLEEPMIN | nunber | 500 | min sleep between each waitForReady |
GRPC_TIMEOUT | number | 20000 | grpc waitforready timeout in MS |
ENDORSE_TIMEOUT | number | 30000 | timeout for endorsement in MS |
EVALUATE_TIMEOUT | number | 30000 | timeout for evaluate in MS |
SUBMIT_TIMEOUT | number | 10000 | timeout for submit in MS |
STATUS_TIMEOUT | number | 60000 | transaction commit notification timeout in MS |
EVENT_TIMEOUT | number | 5000 | chaincode event received timeout in MS |
TRANSACTION_TYPE | 'random','submit','eval' | random | run either submits/evals or a combination |
TXSTATS_TIMER | number | 5000 | check and optionally output stats at given interval in ms (0 = turn off) |
TXSTATS_MODE | 'Stalled', 'Stopped', 'Stalled&Stopped', 'All' | 'All' | output just a warning if client could have stalled or also output txn stats as well. Ignored if TXSTATS_TIMER is 0 |
COLOUR_LOGS | 'true', 'false' | 'true' | add colour to log lines |
The tx stats timer is also used to monitor whether a client may be in total failure mode
Standard log lines go to stdout, stats and stall warnings go to stderr
client README.md has some details about using in docker
In chaos-engine
chaos engine takes 3 parameters
Alternatively run it as a docker container
This will mount the scenarios directory into the container (change the script to use different directories)
check the README.md file in the chaos-engine directory for details about scenarios