Environment
HLF (1.4.2)
Orderer (RAFT 3 Node)
2 Orgs (adding 3rd Org)
Running on multiple hosts (Docker Swarm Cluster)
Steps Followed
Configtx.yaml file contents
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
---
################################################################################
#
# Section: Organizations
#
# - This section defines the different organizational identities which will
# be referenced later in the configuration.
#
################################################################################
Organizations:
- &SFDA
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: SFDAMSP
# ID to load the MSP definition as
ID: SFDAMSP
MSPDir: crypto-config/peerOrganizations/sfda.example.com/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('SFDAMSP.admin', 'SFDAMSP.peer', 'SFDAMSP.client')"
Writers:
Type: Signature
Rule: "OR('SFDAMSP.admin', 'SFDAMSP.client')"
Admins:
Type: Signature
Rule: "OR('SFDAMSP.admin')"
# leave this flag set to true.
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: peer0.sfda.example.com
Port: 7051
crypto-config.yaml
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org3
# ---------------------------------------------------------------------------
- Name: SFDA
Domain: sfda.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
1- Generated Certs
cryptogen generate --config=./crypto-config.yaml
2- Generated Configuration
configtxgen -printOrg SFDAMSP > ./SFDA.json
3- Copied Certs and configuration file into cli
4- Set environment variables for Orderer in CLI and channel name
5- Ran the following set of commands
```
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config >config.json
```
Append the configuration of the new org in **SFDA.json** file into the **config.json** file. Change the file name and MSP in the below command accordingly.
```
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"SFDAMSP":.[1]}}}}}' config.json ./SFDA.json > modified_config.json
```
Verify that the file has been updated
```
diff config.json modified_config.json
```
Package updated configuration into a block and then create a block that is delta of the old and new configuration
```
# Pack config again, create a delta of new and old config
configtxlator proto_encode --input config.json --type common.Config >original_config.pb
configtxlator proto_encode --input modified_config.json --type common.Config >modified_config.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original original_config.pb --updated modified_config.pb >config_update.pb
```
Convert the Delta Block **config_update.pb** block to JSON again, append the header to it and create a package again. Modify the channel name in the second command accordingly
```
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate >config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope >update-block-env.pb
```
6- Set the environment for Peer0 Org1 and Signed the update-block-env.pb
peer channel signconfigtx -f update-block-env.pb
7- Set the environment for Peer0 Org2 and send the transaction to orderer
peer channel update -f update-block-env.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA
8- Deployed the peer and couchdbs
9- Installed chaincode on all peers including new peers added
10- Upgraded the chaincode with the new endorsement policy
11- Sent a transaction and received the following warning.
What would be the implications of this warning in the future or can it can be ignored?
