Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 27 March 2020
6:00am to 7:00am
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 27 March 2020, 6:00am to 7:00am, (GMT+00:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Chain code life cycle endorsement is not working when following changes made in configtx.yaml.

LifecycleEndorsement:
    Type: ImplicitMeta
    Rule: "ANY Endorsement"
Endorsement:
    Type: ImplicitMeta
    Rule: "ANY Endorsement"

Network contains:

• one ordering service cluster with five orderers running Raft
• three organizations (Org1, Org2 and Org3), each of which has one peer (peer0)
• one channel mychannel is created, and peers in all organizations join the channel

Package SACC into chaincode package

• Install chaincode package to peers of all the three organizations
• Org1 approves chaincode package, and tries to commit the chaincode. It fails and getting Endorsement policy error.

But chain code should be commited as LifecycleEndorsement has "Any Endorsement" rule.

Hi Team,

In Hyperleger Fabric 2.0 -

 How to queries QueryInfo, QueryBlock, QueryBlockByHash,  QueryBlockByTxID, QueryTransaction and QueryConfig using fabric-sdk-node client.

As I can see these methods in java and go sdk client but not in fabric-sdk-node.

Kindly Suggest.

Regards,
Shweta

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?

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

crypto-config.yaml

1- Generated Certs

2- Generated Configuration

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

6- Set the environment for Peer0 Org1 and Signed the update-block-env.pb

7- Set the environment for Peer0 Org2 and send the transaction to orderer

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?

caClient.generateCRL({}, adminUser)

original_config_json.channel_group.groups.Application.groups[orgName].values.MSP.value.config.revocation_list = [crl];