From 24f35c14932a0ae622dd32da76ceb33afd635594 Mon Sep 17 00:00:00 2001 From: Angelo De Caro Date: Thu, 15 Feb 2018 13:19:22 +0100 Subject: [PATCH] [FAB-7750] first network with support to FAB-5664 This change-set does the following: - it modifies the first-network example to show how to use FAB-5664. Namely, the identity classification is enabled by setting EnableNodeOUs to true in crypto-config.yaml. Then, the endorsement policy is changed to requires peers and not members. Finally, cryptotx.yaml is modified to enable v1.1 capabilities. Change-Id: If8e943b5833b4402d612895449ac110ab2fee4b5 Signed-off-by: Angelo De Caro --- first-network/configtx.yaml | 55 ++++++++++++++++++++++++++++++++ first-network/crypto-config.yaml | 2 ++ first-network/scripts/utils.sh | 6 ++-- 3 files changed, 60 insertions(+), 3 deletions(-) diff --git a/first-network/configtx.yaml b/first-network/configtx.yaml index e60d789e82..31c545c371 100644 --- a/first-network/configtx.yaml +++ b/first-network/configtx.yaml @@ -15,10 +15,14 @@ Profiles: TwoOrgsOrdererGenesis: + Capabilities: + <<: *ChannelCapabilities Orderer: <<: *OrdererDefaults Organizations: - *OrdererOrg + Capabilities: + <<: *OrdererCapabilities Consortiums: SampleConsortium: Organizations: @@ -31,6 +35,8 @@ Profiles: Organizations: - *Org1 - *Org2 + Capabilities: + <<: *ApplicationCapabilities ################################################################################ # @@ -147,3 +153,52 @@ Application: &ApplicationDefaults # Organizations is the list of orgs which are defined as participants on # the application side of the network Organizations: + +################################################################################ +# +# SECTION: Capabilities +# +# - This section defines the capabilities of fabric network. This is a new +# concept as of v1.1.0 and should not be utilized in mixed networks with +# v1.0.x peers and orderers. Capabilities define features which must be +# present in a fabric binary for that binary to safely participate in the +# fabric network. For instance, if a new MSP type is added, newer binaries +# might recognize and validate the signatures from this type, while older +# binaries without this support would be unable to validate those +# transactions. This could lead to different versions of the fabric binaries +# having different world states. Instead, defining a capability for a channel +# informs those binaries without this capability that they must cease +# processing transactions until they have been upgraded. For v1.0.x if any +# capabilities are defined (including a map with all capabilities turned off) +# then the v1.0.x peer will deliberately crash. +# +################################################################################ +Capabilities: + # Channel capabilities apply to both the orderers and the peers and must be + # supported by both. Set the value of the capability to true to require it. + Global: &ChannelCapabilities + # V1.1 for Global is a catchall flag for behavior which has been + # determined to be desired for all orderers and peers running v1.0.x, + # but the modification of which would cause incompatibilities. Users + # should leave this flag set to true. + V1_1: true + + # Orderer capabilities apply only to the orderers, and may be safely + # manipulated without concern for upgrading peers. Set the value of the + # capability to true to require it. + Orderer: &OrdererCapabilities + # V1.1 for Order is a catchall flag for behavior which has been + # determined to be desired for all orderers running v1.0.x, but the + # modification of which would cause incompatibilities. Users should + # leave this flag set to true. + V1_1: true + + # Application capabilities apply only to the peer network, and may be safely + # manipulated without concern for upgrading orderers. Set the value of the + # capability to true to require it. + Application: &ApplicationCapabilities + # V1.1 for Application is a catchall flag for behavior which has been + # determined to be desired for all peers running v1.0.x, but the + # modification of which would cause incompatibilities. Users should + # leave this flag set to true. + V1_1: true diff --git a/first-network/crypto-config.yaml b/first-network/crypto-config.yaml index 06ad8185cd..73b444d8cd 100644 --- a/first-network/crypto-config.yaml +++ b/first-network/crypto-config.yaml @@ -26,6 +26,7 @@ PeerOrgs: # --------------------------------------------------------------------------- - Name: Org1 Domain: org1.example.com + EnableNodeOUs: true # --------------------------------------------------------------------------- # "Specs" # --------------------------------------------------------------------------- @@ -75,6 +76,7 @@ PeerOrgs: # --------------------------------------------------------------------------- - Name: Org2 Domain: org2.example.com + EnableNodeOUs: true Template: Count: 2 Users: diff --git a/first-network/scripts/utils.sh b/first-network/scripts/utils.sh index 12d07327cc..dd481c0e78 100755 --- a/first-network/scripts/utils.sh +++ b/first-network/scripts/utils.sh @@ -116,9 +116,9 @@ instantiateChaincode () { # while 'peer chaincode' command can get the orderer endpoint from the peer (if join was successful), # lets supply it directly as we know it using the "-o" option if [ -z "$CORE_PEER_TLS_ENABLED" -o "$CORE_PEER_TLS_ENABLED" = "false" ]; then - peer chaincode instantiate -o orderer.example.com:7050 -C $CHANNEL_NAME -n mycc -l ${LANGUAGE} -v ${VERSION} -c '{"Args":["init","a","100","b","200"]}' -P "OR ('Org1MSP.member','Org2MSP.member')" >&log.txt + peer chaincode instantiate -o orderer.example.com:7050 -C $CHANNEL_NAME -n mycc -l ${LANGUAGE} -v ${VERSION} -c '{"Args":["init","a","100","b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')" >&log.txt else - peer chaincode instantiate -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -l ${LANGUAGE} -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR ('Org1MSP.member','Org2MSP.member')" >&log.txt + peer chaincode instantiate -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -l ${LANGUAGE} -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')" >&log.txt fi res=$? cat log.txt @@ -132,7 +132,7 @@ upgradeChaincode () { ORG=$2 setGlobals $PEER $ORG - peer chaincode upgrade -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -v 2.0 -c '{"Args":["init","a","90","b","210"]}' -P "OR ('Org1MSP.member','Org2MSP.member','Org3MSP.member')" + peer chaincode upgrade -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -v 2.0 -c '{"Args":["init","a","90","b","210"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')" res=$? cat log.txt verifyResult $res "Chaincode upgrade on org${ORG} peer${PEER} has Failed"