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?