Date   

Re: Inconsistent Private Data Collection Write operation

Hritik Gupta <hritikgupta9@...>
 

I haven't mentioned any chaincode endorsement policy during deployment thinking that the collection level endorsement policy overrides the chaincode level policy.
The collection level policy is: "OR('Org1MSP.member', 'Org2MSP.member')". 

According to the documentation, "You can use collection-level endorsement policies to restrict which organization peers can write to the private data collection key namespace". Since the intent is allowing only these 2 org peers to allow writing to private data, hence the policy is so. 
Since there is one peer per org, that makes 2 endorsing peers. I'm not sure what the second question means. Since there are the only 2 peers in the network, I'm thus getting endorsement from the same exact peers.

PFA the peer0.org1 logs screenshot.
On a side note, I'm trying to implement a variant of the bidding pattern you've suggested here: https://lists.hyperledger.org/g/fabric/message/7554; keeping Org1 analogous to the seller that persists on its private collection the bids of sellers (Org2).

Thanks.


On Fri, Jun 19, 2020 at 7:05 PM David Enyeart <enyeart@...> wrote:

The second scenario failed due to:
2020-06-19 12:45:35.053 UTC [policies] SignatureSetToValidIdentities -> WARN 0ef signature for identity 0 is invalid: The signature is invalid

How many peers are endorsing? Are you always getting endorsement from the same exact peers?
What is the endorsement policy for both the chaincode and the collection?
Can you provide the uninterrupted log?


Dave Enyeart

"Hritik Gupta" ---06/19/2020 09:01:25 AM---I have attached the screenshots of the logs from Org1 peer container for your reference, for better

From: "Hritik Gupta" <hritikgupta9@...>
To: "email4tong@..." <email4tong@...>
Cc: David Enyeart <enyeart@...>, Cendhu U <cendhu@...>, fabric <fabric@...>
Date: 06/19/2020 09:01 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Inconsistent Private Data Collection Write operation
Sent by: fabric@...





I have attached the screenshots of the logs from Org1 peer container for your reference, for better readability. 

Logs when it worked:
2020-06-19 12:49:09.580 UTC [comm.grpc.server] 1 -> INFO 122 unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=192.168.112.1:57578 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=679.842µs
2020-06-19 12:49:09.608 UTC [comm.grpc.server] 1 -> INFO 123 unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=
192.168.112.1:57578 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=813.325µs
2020-06-19 12:49:09.622 UTC [endorser] callChaincode -> INFO 124 finished chaincode: fabcar duration: 1ms channel=mychannel txID=de27f4ec
2020-06-19 12:49:09.635
UTC [comm.grpc.server] 1 -> INFO 125 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.112.1:57586 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=14.715518ms
2020-06-19 12:49:11.678
UTC [gossip.privdata] StoreBlock -> INFO 126 [mychannel] Received block [20] from buffer
2020-06-19 12:49:11.680
UTC [committer.txvalidator] Validate -> INFO 127 [mychannel] Validated block [20] in 2ms
2020-06-19 12:49:11.681
UTC [gossip.privdata] prepareBlockPvtdata -> INFO 128 Successfully fetched all eligible collection private write sets for block [20] channel=mychannel
2020-06-19 12:49:11.712
UTC [kvledger] CommitLegacy -> INFO 129 [mychannel] Committed block [20] with 1 transaction(s) in 30ms (state_validation=0ms block_and_pvtdata_commit=18ms state_commit=5ms) commitHash=[6bfa36ced7abf414a278943a0efe5cc5bbbfeecb9ef5edce84b862e314b688c4]
2020-06-19 12:49:11.723
UTC [comm.grpc.server] 1 -> INFO 12a streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=192.168.112.1:57594 grpc.peer_subject="CN=fabric-common" error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.075316216s

Logs when it failed:
2020-06-19 12:45:31.198 UTC [comm.grpc.server] 1 -> INFO 0ea unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=192.168.112.1:57492 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=805.632µs
2020-06-19 12:45:31.224 UTC [comm.grpc.server] 1 -> INFO 0eb unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=
192.168.112.1:57492 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=757.737µs
2020-06-19 12:45:31.238 UTC [endorser] callChaincode -> INFO 0ec finished chaincode: fabcar duration: 1ms channel=mychannel txID=ee3f5ebe
2020-06-19 12:45:31.775 UTC [comm.grpc.server] 1 -> INFO 0ed unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=
192.168.112.1:57500 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=539.382571ms
2020-06-19 12:45:35.051 UTC [gossip.privdata] StoreBlock -> INFO 0ee [mychannel] Received block [16] from buffer

2020-06-19 12:45:35.053 UTC
[policies] SignatureSetToValidIdentities -> WARN 0ef signature for identity 0 is invalid: The signature is invalid
2020-06-19 12:45:35.054 UTC
[policies] SignatureSetToValidIdentities -> WARN 0f0 signature for identity 0 is invalid: The signature is invalid
2020-06-19 12:45:35.054 UTC
[vscc] Validate -> ERRO 0f1 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode fabcar in tx 16:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-06-19 12:45:35.054 UTC
[committer.txvalidator] validateTx -> ERRO 0f2 Dispatch for transaction txId = ee3f5ebe9aee21b245ef1ceb376e0e8facfd0b71965c2defae37d5a70b3558db returned error: validation of endorsement policy for chaincode fabcar in tx 16:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-06-19 12:45:35.054 UTC
[committer.txvalidator] Validate -> INFO 0f3 [mychannel] Validated block [16] in 3ms
2020-06-19 12:45:35.054 UTC
[gossip.privdata] prepareBlockPvtdata -> INFO 0f4 Successfully fetched all eligible collection private write sets for block [16] channel=mychannel
2020-06-19 12:45:35.055 UTC
[valimpl] preprocessProtoBlock -> WARN 0f5 Channel [mychannel]: Block [16] Transaction index [0] TxId [ee3f5ebe9aee21b245ef1ceb376e0e8facfd0b71965c2defae37d5a70b3558db] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-06-19 12:45:36.879 UTC [kvledger] CommitLegacy -> INFO 0f6 [mychannel] Committed block [16] with 1 transaction(s) in 1824ms (state_validation=0ms block_and_pvtdata_commit=1075ms state_commit=363ms) commitHash=[0caec1920f414394bd085c351bf04c66b18ee0d67c9d7313687b9216e79261d5]

2020-06-19 12:45:36.893 UTC
[comm.grpc.server] 1 -> INFO 0f7 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=192.168.112.1:57508 grpc.peer_subject="CN=fabric-common" error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=5.099824363s

@email4tong : I tried deploying the chaincode with this policy, it gave me an Error: invalid collection configuration: invalid endorsement policy. 

Thanks.

On Fri, Jun 19, 2020 at 6:05 PM email4tong@... <email4tong@...> wrote:
    Curious about this policy,

    "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }


    was it accepted as a valid policy? if it was accepted, should this be a bug? what does this policy exactly mean? Is it the same as this

    "endorsementPolicy": {
          "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
        }


    Thanks.

    On Friday, June 19, 2020, 8:29:10 AM EDT, David Enyeart <enyeart@...> wrote:

    The endorsement policy check only checks which peers have endorsed, not which clients have submitted the transaction. The peer validation logic is deterministic in this regard.
    Could you share the Org1 peer log showing it working once, and not working once, with no other changes inbetween? Please highlight the log timestamp of endorsement and validation in both cases.


    Thanks,

    Dave Enyeart

    "Hritik Gupta" ---06/19/2020 08:11:18 AM---I ran the network again, to double check. The inconsistency issue still exists. The issue occurs eve

    From:
    "Hritik Gupta" <hritikgupta9@...>
    To:
    Cendhu U <cendhu@...>
    Cc:
    fabric <fabric@...>
    Date:
    06/19/2020 08:11 AM
    Subject:
    [EXTERNAL] Re: [Hyperledger Fabric] Inconsistent Private Data Collection Write operation
    Sent by:
    fabric@...





    I ran the network again, to double check. The inconsistency issue still exists. The issue occurs even when I pass OR("Org1MSP.Member") as the EP and try to update the key via Org1 client (which is an authorized peer).




    On Fri, Jun 19, 2020 at 5:31 PM Cendhu U <
    cendhu@...> wrote:
    but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

    the above error seems to match your old definition --
    "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }

    Anyway, I do not have expertise in this. If Yacov looks at this message, he might clarify
    .

    Regards,
    Senthil

    On Fri, Jun 19, 2020 at 5:21 PM Hritik Gupta <
    hritikgupta9@...> wrote:
    Sorry for typing it wrong. The endorsement policy in my collections config is as follows:

    "endorsementPolicy": {
          "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
        }

    Setting memberOnlyWrite to false is deliberate because I want the peers of only Org2 and Org1 to be able to write to the private data collection; and not any other Org that might join the network in future. 


    -- 












--



Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 06/19/2020 4:00pm-5:00pm #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 19 June 2020, 4:00pm to 5:00pm, (GMT+01: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


Re: Inconsistent Private Data Collection Write operation

David Enyeart
 

The second scenario failed due to:
2020-06-19 12:45:35.053 UTC [policies] SignatureSetToValidIdentities -> WARN 0ef signature for identity 0 is invalid: The signature is invalid

How many peers are endorsing? Are you always getting endorsement from the same exact peers?
What is the endorsement policy for both the chaincode and the collection?
Can you provide the uninterrupted log?


Dave Enyeart

"Hritik Gupta" ---06/19/2020 09:01:25 AM---I have attached the screenshots of the logs from Org1 peer container for your reference, for better

From: "Hritik Gupta" <hritikgupta9@...>
To: "email4tong@..." <email4tong@...>
Cc: David Enyeart <enyeart@...>, Cendhu U <cendhu@...>, fabric <fabric@...>
Date: 06/19/2020 09:01 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Inconsistent Private Data Collection Write operation
Sent by: fabric@...





I have attached the screenshots of the logs from Org1 peer container for your reference, for better readability. 

Logs when it worked:
2020-06-19 12:49:09.580 UTC [comm.grpc.server] 1 -> INFO 122 unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=192.168.112.1:57578 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=679.842µs
2020-06-19 12:49:09.608 UTC [comm.grpc.server] 1 -> INFO 123 unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=
192.168.112.1:57578 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=813.325µs
2020-06-19 12:49:09.622 UTC [endorser] callChaincode -> INFO 124 finished chaincode: fabcar duration: 1ms channel=mychannel txID=de27f4ec
2020-06-19 12:49:09.635
UTC [comm.grpc.server] 1 -> INFO 125 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.112.1:57586 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=14.715518ms
2020-06-19 12:49:11.678
UTC [gossip.privdata] StoreBlock -> INFO 126 [mychannel] Received block [20] from buffer
2020-06-19 12:49:11.680
UTC [committer.txvalidator] Validate -> INFO 127 [mychannel] Validated block [20] in 2ms
2020-06-19 12:49:11.681
UTC [gossip.privdata] prepareBlockPvtdata -> INFO 128 Successfully fetched all eligible collection private write sets for block [20] channel=mychannel
2020-06-19 12:49:11.712
UTC [kvledger] CommitLegacy -> INFO 129 [mychannel] Committed block [20] with 1 transaction(s) in 30ms (state_validation=0ms block_and_pvtdata_commit=18ms state_commit=5ms) commitHash=[6bfa36ced7abf414a278943a0efe5cc5bbbfeecb9ef5edce84b862e314b688c4]
2020-06-19 12:49:11.723
UTC [comm.grpc.server] 1 -> INFO 12a streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=192.168.112.1:57594 grpc.peer_subject="CN=fabric-common" error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.075316216s

Logs when it failed:
2020-06-19 12:45:31.198 UTC [comm.grpc.server] 1 -> INFO 0ea unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=192.168.112.1:57492 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=805.632µs
2020-06-19 12:45:31.224 UTC [comm.grpc.server] 1 -> INFO 0eb unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=
192.168.112.1:57492 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=757.737µs
2020-06-19 12:45:31.238 UTC [endorser] callChaincode -> INFO 0ec finished chaincode: fabcar duration: 1ms channel=mychannel txID=ee3f5ebe
2020-06-19 12:45:31.775 UTC [comm.grpc.server] 1 -> INFO 0ed unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=
192.168.112.1:57500 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=539.382571ms
2020-06-19 12:45:35.051 UTC [gossip.privdata] StoreBlock -> INFO 0ee [mychannel] Received block [16] from buffer

2020-06-19 12:45:35.053 UTC
[policies] SignatureSetToValidIdentities -> WARN 0ef signature for identity 0 is invalid: The signature is invalid
2020-06-19 12:45:35.054 UTC
[policies] SignatureSetToValidIdentities -> WARN 0f0 signature for identity 0 is invalid: The signature is invalid
2020-06-19 12:45:35.054 UTC
[vscc] Validate -> ERRO 0f1 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode fabcar in tx 16:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-06-19 12:45:35.054 UTC
[committer.txvalidator] validateTx -> ERRO 0f2 Dispatch for transaction txId = ee3f5ebe9aee21b245ef1ceb376e0e8facfd0b71965c2defae37d5a70b3558db returned error: validation of endorsement policy for chaincode fabcar in tx 16:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-06-19 12:45:35.054 UTC
[committer.txvalidator] Validate -> INFO 0f3 [mychannel] Validated block [16] in 3ms
2020-06-19 12:45:35.054 UTC
[gossip.privdata] prepareBlockPvtdata -> INFO 0f4 Successfully fetched all eligible collection private write sets for block [16] channel=mychannel
2020-06-19 12:45:35.055 UTC
[valimpl] preprocessProtoBlock -> WARN 0f5 Channel [mychannel]: Block [16] Transaction index [0] TxId [ee3f5ebe9aee21b245ef1ceb376e0e8facfd0b71965c2defae37d5a70b3558db] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-06-19 12:45:36.879 UTC [kvledger] CommitLegacy -> INFO 0f6 [mychannel] Committed block [16] with 1 transaction(s) in 1824ms (state_validation=0ms block_and_pvtdata_commit=1075ms state_commit=363ms) commitHash=[0caec1920f414394bd085c351bf04c66b18ee0d67c9d7313687b9216e79261d5]

2020-06-19 12:45:36.893 UTC
[comm.grpc.server] 1 -> INFO 0f7 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=192.168.112.1:57508 grpc.peer_subject="CN=fabric-common" error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=5.099824363s

@email4tong : I tried deploying the chaincode with this policy, it gave me an Error: invalid collection configuration: invalid endorsement policy. 

Thanks.

On Fri, Jun 19, 2020 at 6:05 PM email4tong@... <email4tong@...> wrote:
    Curious about this policy,

    "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }


    was it accepted as a valid policy? if it was accepted, should this be a bug? what does this policy exactly mean? Is it the same as this

    "endorsementPolicy": {
          "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
        }


    Thanks.


On Friday, June 19, 2020, 8:29:10 AM EDT, David Enyeart <enyeart@...> wrote:

The endorsement policy check only checks which peers have endorsed, not which clients have submitted the transaction. The peer validation logic is deterministic in this regard.
Could you share the Org1 peer log showing it working once, and not working once, with no other changes inbetween? Please highlight the log timestamp of endorsement and validation in both cases.


Thanks,

Dave Enyeart

"Hritik Gupta" ---06/19/2020 08:11:18 AM---I ran the network again, to double check. The inconsistency issue still exists. The issue occurs eve

From:
"Hritik Gupta" <hritikgupta9@...>
To:
Cendhu U <cendhu@...>
Cc:
fabric <fabric@...>
Date:
06/19/2020 08:11 AM
Subject:
[EXTERNAL] Re: [Hyperledger Fabric] Inconsistent Private Data Collection Write operation
Sent by:
fabric@...





I ran the network again, to double check. The inconsistency issue still exists. The issue occurs even when I pass OR("Org1MSP.Member") as the EP and try to update the key via Org1 client (which is an authorized peer).




On Fri, Jun 19, 2020 at 5:31 PM Cendhu U <
cendhu@...> wrote:
but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

the above error seems to match your old definition --
"endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }

Anyway, I do not have expertise in this. If Yacov looks at this message, he might clarify
.

Regards,
Senthil

On Fri, Jun 19, 2020 at 5:21 PM Hritik Gupta <
hritikgupta9@...> wrote:
Sorry for typing it wrong. The endorsement policy in my collections config is as follows:

"endorsementPolicy": {
      "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
    }

Setting memberOnlyWrite to false is deliberate because I want the peers of only Org2 and Org1 to be able to write to the private data collection; and not any other Org that might join the network in future. 


-- 











Re: How to verify RAFT health in HLF version 1.4.4 #raft

Jason Yellick <jyellick@...>
 

For v1.4.x, there is no metric to check the set of active nodes.  Usually, it's adequate to simply ensure that all OSNs are alive and have been online for a reasonable period of time to ensure that the Raft cluster has all nodes active.

There are ways to detect nodes out of quorum, but it is a little tedious.  When a node is not part of the Raft quorum, it will make services for that channel unavailable, so, you may attempt to pull a block via the Deliver interface from each OSN on a channel, and those which respond with SERVICE_UNAVAILABLE are not active in the Raft cluster currently.

As was pointed out in your original e-mail, the "consensus_etcdraft_active_nodes" metric was added into v2.0 to address this operational aspect.  It was not back-ported to v1.4.x because the code change required new messages on the wire, and was considered to be too invasive for an LTS release.

Thanks,
~Jason
 
 

----- Original message -----
From: "Senthil Nathan" <cendhu@...>
Sent by: fabric@...
To: shrugupt@...
Cc: fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] How to verify RAFT health in HLF version 1.4.4 #raft
Date: Fri, Jun 19, 2020 7:12 AM
   
On Fri, Jun 19, 2020 at 9:38 AM shrugupt via lists.hyperledger.org <shrugupt=microsoft.com@...> wrote:
Hi,

Would really appreciate if anybody has any thought/suggestion regarding my query.

Thanks,
Shruti

 

 

 

 


Re: Inconsistent Private Data Collection Write operation

Hritik Gupta <hritikgupta9@...>
 

I have attached the screenshots of the logs from Org1 peer container for your reference, for better readability. 

Logs when it worked:
2020-06-19 12:49:09.580 UTC [comm.grpc.server] 1 -> INFO 122 unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=192.168.112.1:57578 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=679.842µs
2020-06-19 12:49:09.608 UTC [comm.grpc.server] 1 -> INFO 123 unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=192.168.112.1:57578 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=813.325µs
2020-06-19 12:49:09.622 UTC [endorser] callChaincode -> INFO 124 finished chaincode: fabcar duration: 1ms channel=mychannel txID=de27f4ec
2020-06-19 12:49:09.635 UTC [comm.grpc.server] 1 -> INFO 125 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.112.1:57586 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=14.715518ms
2020-06-19 12:49:11.678 UTC [gossip.privdata] StoreBlock -> INFO 126 [mychannel] Received block [20] from buffer
2020-06-19 12:49:11.680 UTC [committer.txvalidator] Validate -> INFO 127 [mychannel] Validated block [20] in 2ms
2020-06-19 12:49:11.681 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 128 Successfully fetched all eligible collection private write sets for block [20] channel=mychannel
2020-06-19 12:49:11.712 UTC [kvledger] CommitLegacy -> INFO 129 [mychannel] Committed block [20] with 1 transaction(s) in 30ms (state_validation=0ms block_and_pvtdata_commit=18ms state_commit=5ms) commitHash=[6bfa36ced7abf414a278943a0efe5cc5bbbfeecb9ef5edce84b862e314b688c4]
2020-06-19 12:49:11.723 UTC [comm.grpc.server] 1 -> INFO 12a streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=192.168.112.1:57594 grpc.peer_subject="CN=fabric-common" error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.075316216s

Logs when it failed:
2020-06-19 12:45:31.198 UTC [comm.grpc.server] 1 -> INFO 0ea unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=192.168.112.1:57492 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=805.632µs
2020-06-19 12:45:31.224 UTC [comm.grpc.server] 1 -> INFO 0eb unary call completed grpc.service=discovery.Discovery grpc.method=Discover grpc.peer_address=192.168.112.1:57492 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=757.737µs
2020-06-19 12:45:31.238 UTC [endorser] callChaincode -> INFO 0ec finished chaincode: fabcar duration: 1ms channel=mychannel txID=ee3f5ebe
2020-06-19 12:45:31.775 UTC [comm.grpc.server] 1 -> INFO 0ed unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.112.1:57500 grpc.peer_subject="CN=fabric-common" grpc.code=OK grpc.call_duration=539.382571ms
2020-06-19 12:45:35.051 UTC [gossip.privdata] StoreBlock -> INFO 0ee [mychannel] Received block [16] from buffer
2020-06-19 12:45:35.053 UTC [policies] SignatureSetToValidIdentities -> WARN 0ef signature for identity 0 is invalid: The signature is invalid
2020-06-19 12:45:35.054 UTC [policies] SignatureSetToValidIdentities -> WARN 0f0 signature for identity 0 is invalid: The signature is invalid
2020-06-19 12:45:35.054 UTC [vscc] Validate -> ERRO 0f1 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode fabcar in tx 16:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-06-19 12:45:35.054 UTC [committer.txvalidator] validateTx -> ERRO 0f2 Dispatch for transaction txId = ee3f5ebe9aee21b245ef1ceb376e0e8facfd0b71965c2defae37d5a70b3558db returned error: validation of endorsement policy for chaincode fabcar in tx 16:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-06-19 12:45:35.054 UTC [committer.txvalidator] Validate -> INFO 0f3 [mychannel] Validated block [16] in 3ms
2020-06-19 12:45:35.054 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0f4 Successfully fetched all eligible collection private write sets for block [16] channel=mychannel
2020-06-19 12:45:35.055 UTC [valimpl] preprocessProtoBlock -> WARN 0f5 Channel [mychannel]: Block [16] Transaction index [0] TxId [ee3f5ebe9aee21b245ef1ceb376e0e8facfd0b71965c2defae37d5a70b3558db] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-06-19 12:45:36.879 UTC [kvledger] CommitLegacy -> INFO 0f6 [mychannel] Committed block [16] with 1 transaction(s) in 1824ms (state_validation=0ms block_and_pvtdata_commit=1075ms state_commit=363ms) commitHash=[0caec1920f414394bd085c351bf04c66b18ee0d67c9d7313687b9216e79261d5]
2020-06-19 12:45:36.893 UTC [comm.grpc.server] 1 -> INFO 0f7 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=192.168.112.1:57508 grpc.peer_subject="CN=fabric-common" error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=5.099824363s

@email4tong : I tried deploying the chaincode with this policy, it gave me an Error: invalid collection configuration: invalid endorsement policy. 

Thanks.

On Fri, Jun 19, 2020 at 6:05 PM email4tong@... <email4tong@...> wrote:
Curious about this policy,

"endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }


was it accepted as a valid policy? if it was accepted, should this be a bug? what does this policy exactly mean? Is it the same as this

"endorsementPolicy": {
      "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
    }

Thanks.

On Friday, June 19, 2020, 8:29:10 AM EDT, David Enyeart <enyeart@...> wrote:


The endorsement policy check only checks which peers have endorsed, not which clients have submitted the transaction. The peer validation logic is deterministic in this regard.
Could you share the Org1 peer log showing it working once, and not working once, with no other changes inbetween? Please highlight the log timestamp of endorsement and validation in both cases.


Thanks,

Dave Enyeart

"Hritik Gupta" ---06/19/2020 08:11:18 AM---I ran the network again, to double check. The inconsistency issue still exists. The issue occurs eve

From: "Hritik Gupta" <hritikgupta9@...>
To: Cendhu U <cendhu@...>
Cc: fabric <fabric@...>
Date: 06/19/2020 08:11 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Inconsistent Private Data Collection Write operation
Sent by: fabric@...





I ran the network again, to double check. The inconsistency issue still exists. The issue occurs even when I pass OR("Org1MSP.Member") as the EP and try to update the key via Org1 client (which is an authorized peer).



On Fri, Jun 19, 2020 at 5:31 PM Cendhu U <cendhu@...> wrote:
    but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

      the above error seems to match your old definition -- "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }

      Anyway, I do not have expertise in this. If Yacov looks at this message, he might clarify.

      Regards,
      Senthil

      On Fri, Jun 19, 2020 at 5:21 PM Hritik Gupta <hritikgupta9@...> wrote:
      Sorry for typing it wrong. The endorsement policy in my collections config is as follows:

      "endorsementPolicy": {
            "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
          }

      Setting memberOnlyWrite to false is deliberate because I want the peers of only Org2 and Org1 to be able to write to the private data collection; and not any other Org that might join the network in future. 



      -- 









      Re: Inconsistent Private Data Collection Write operation

      email4tong@gmail.com
       

      Curious about this policy,

      "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }


      was it accepted as a valid policy? if it was accepted, should this be a bug? what does this policy exactly mean? Is it the same as this

      "endorsementPolicy": {
            "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
          }

      Thanks.

      On Friday, June 19, 2020, 8:29:10 AM EDT, David Enyeart <enyeart@...> wrote:


      The endorsement policy check only checks which peers have endorsed, not which clients have submitted the transaction. The peer validation logic is deterministic in this regard.
      Could you share the Org1 peer log showing it working once, and not working once, with no other changes inbetween? Please highlight the log timestamp of endorsement and validation in both cases.


      Thanks,

      Dave Enyeart

      "Hritik Gupta" ---06/19/2020 08:11:18 AM---I ran the network again, to double check. The inconsistency issue still exists. The issue occurs eve

      From: "Hritik Gupta" <hritikgupta9@...>
      To: Cendhu U <cendhu@...>
      Cc: fabric <fabric@...>
      Date: 06/19/2020 08:11 AM
      Subject: [EXTERNAL] Re: [Hyperledger Fabric] Inconsistent Private Data Collection Write operation
      Sent by: fabric@...





      I ran the network again, to double check. The inconsistency issue still exists. The issue occurs even when I pass OR("Org1MSP.Member") as the EP and try to update the key via Org1 client (which is an authorized peer).



      On Fri, Jun 19, 2020 at 5:31 PM Cendhu U <cendhu@...> wrote:
        but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

          the above error seems to match your old definition -- "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }

          Anyway, I do not have expertise in this. If Yacov looks at this message, he might clarify.

          Regards,
          Senthil

          On Fri, Jun 19, 2020 at 5:21 PM Hritik Gupta <hritikgupta9@...> wrote:
          Sorry for typing it wrong. The endorsement policy in my collections config is as follows:

          "endorsementPolicy": {
                "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
              }

          Setting memberOnlyWrite to false is deliberate because I want the peers of only Org2 and Org1 to be able to write to the private data collection; and not any other Org that might join the network in future. 



          -- 





          Re: Inconsistent Private Data Collection Write operation

          David Enyeart
           

          The endorsement policy check only checks which peers have endorsed, not which clients have submitted the transaction. The peer validation logic is deterministic in this regard.
          Could you share the Org1 peer log showing it working once, and not working once, with no other changes inbetween? Please highlight the log timestamp of endorsement and validation in both cases.


          Thanks,

          Dave Enyeart

          "Hritik Gupta" ---06/19/2020 08:11:18 AM---I ran the network again, to double check. The inconsistency issue still exists. The issue occurs eve

          From: "Hritik Gupta" <hritikgupta9@...>
          To: Cendhu U <cendhu@...>
          Cc: fabric <fabric@...>
          Date: 06/19/2020 08:11 AM
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] Inconsistent Private Data Collection Write operation
          Sent by: fabric@...





          I ran the network again, to double check. The inconsistency issue still exists. The issue occurs even when I pass OR("Org1MSP.Member") as the EP and try to update the key via Org1 client (which is an authorized peer).



          On Fri, Jun 19, 2020 at 5:31 PM Cendhu U <cendhu@...> wrote:
            but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

            the above error seems to match your old definition -- "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }

            Anyway, I do not have expertise in this. If Yacov looks at this message, he might clarify.

            Regards,
            Senthil


          On Fri, Jun 19, 2020 at 5:21 PM Hritik Gupta <hritikgupta9@...> wrote:
          Sorry for typing it wrong. The endorsement policy in my collections config is as follows:

          "endorsementPolicy": {
                "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
              }

          Setting memberOnlyWrite to false is deliberate because I want the peers of only Org2 and Org1 to be able to write to the private data collection; and not any other Org that might join the network in future. 



          -- 





          Re: Creation of couchdb index on an already running network #couchdb #fabric-chaincode

          Senthil Nathan
           

          If couchdb returned an error status code while processing the index, we do log the error but chaincode upgrade would succeed irrespective of that. I would suggest to search for the term index to see what is present in the log. If nothing related to index is logged, it is better to check the chaincode package to see whether the index is placed at the correct location.

          Regards,
          Senthil

          On Fri, 19 Jun, 2020, 5:47 pm Joao Antunes, <joao.antunes@...> wrote:

          What should I search for in the peer logs?

          Some sort of error?

          Because I can't see the index on the couchdb entries


          Re: Creation of couchdb index on an already running network #couchdb #fabric-chaincode

          Joao Antunes
           

          What should I search for in the peer logs?

          Some sort of error?

          Because I can't see the index on the couchdb entries


          Re: Inconsistent Private Data Collection Write operation

          Hritik Gupta <hritikgupta9@...>
           

          I ran the network again, to double check. The inconsistency issue still exists. The issue occurs even when I pass OR("Org1MSP.Member") as the EP and try to update the key via Org1 client (which is an authorized peer).



          On Fri, Jun 19, 2020 at 5:31 PM Cendhu U <cendhu@...> wrote:
          but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

          the above error seems to match your old definition -- "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }

          Anyway, I do not have expertise in this. If Yacov looks at this message, he might clarify.

          Regards,
          Senthil

          On Fri, Jun 19, 2020 at 5:21 PM Hritik Gupta <hritikgupta9@...> wrote:
          Sorry for typing it wrong. The endorsement policy in my collections config is as follows:

          "endorsementPolicy": {
                "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
              }

          Setting memberOnlyWrite to false is deliberate because I want the peers of only Org2 and Org1 to be able to write to the private data collection; and not any other Org that might join the network in future. 



          -- 


          Re: Creation of couchdb index on an already running network #couchdb #fabric-chaincode

          Senthil Nathan
           

          Do you have the peer logs?

          Regards,
          Senthil


          On Fri, Jun 19, 2020 at 5:22 PM Joao Antunes <joao.antunes@...> wrote:

          Hi,

          I currently trying to add a new index to my 1.4 network.

          I have the folders correctly set too. When  I update the chaincode with the new index folder I can see that my peers have the package correctly but I can't see the index in the couchdb of my peer. Am I missing something?

          Thank you.


          Re: Inconsistent Private Data Collection Write operation

          Senthil Nathan
           

          but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

          the above error seems to match your old definition -- "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }

          Anyway, I do not have expertise in this. If Yacov looks at this message, he might clarify.

          Regards,
          Senthil

          On Fri, Jun 19, 2020 at 5:21 PM Hritik Gupta <hritikgupta9@...> wrote:
          Sorry for typing it wrong. The endorsement policy in my collections config is as follows:

          "endorsementPolicy": {
                "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
              }

          Setting memberOnlyWrite to false is deliberate because I want the peers of only Org2 and Org1 to be able to write to the private data collection; and not any other Org that might join the network in future. 


          Creation of couchdb index on an already running network #couchdb #fabric-chaincode

          Joao Antunes
           

          Hi,

          I currently trying to add a new index to my 1.4 network.

          I have the folders correctly set too. When  I update the chaincode with the new index folder I can see that my peers have the package correctly but I can't see the index in the couchdb of my peer. Am I missing something?

          Thank you.


          Re: Inconsistent Private Data Collection Write operation

          Hritik Gupta <hritikgupta9@...>
           

          Sorry for typing it wrong. The endorsement policy in my collections config is as follows:

          "endorsementPolicy": {
                "signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
              }

          Setting memberOnlyWrite to false is deliberate because I want the peers of only Org2 and Org1 to be able to write to the private data collection; and not any other Org that might join the network in future. 


          Re: Inconsistent Private Data Collection Write operation

          Senthil Nathan
           

          1) an authorized peer
          2) an unauthorized peer after making the following change to the collection endorsement policy:
          "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" }

          1. As the memberOnlyWrite is set to false by default (not configured in the collection config as well), all peers are authorized to write if it can satisfy the endorsement policy.
          2. Is the endorsement policy syntax correct for your scenario? Shouldn't it be "OR('Org1MSP.member', 'Org2MSP.member')" if you want to allow either of the organization to write to the collection?
          Regards,
          Senthil


          On Fri, Jun 19, 2020 at 3:54 PM Hritik Gupta <hritikgupta9@...> wrote:
          Hi all,

          I have a fabric 2.0 network with 2 orgs having 1 peer each (similar to test-network). I implemented a private data collection that persists in the off-chain DB of the peer of one of the orgs (Org1, as shown below)
          "name": "collectionMarblePrivateDetails", 
          "policy": "OR('Org1MSP.member')", 
          "requiredPeerCount": 0, 
          "maxPeerCount": 3, 
          "blockToLive": 0, 
          "memberOnlyRead": true, 
          "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member')" } 
          }
          I tried to change the value of the key in the private collection by invoking the relevant chaincode method from : (I'm using the submitTransaction method from the Contract class of fabric node-sdk) 
          1) an authorized peer
          2) an unauthorized peer after making the following change to the collection endorsement policy:
          "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" } 

          Although the above 2 operations work sometimes, but very inconsistently. It fails by giving the following endorsement policy error:

          2020-06-19T10:01:19.660Z - warn: [TransactionEventHandler]: strategyFail: commit failure for transaction "8a06bccc8afd555efb4c1a70ac0ce1905c17f135061ca1ec525d760c0101118d": Error: Commit of transaction 8a06bccc8afd555efb4c1a70ac0ce1905c17f135061ca1ec525d760c0101118d failed on peer peer0.org1.example.com:7051 with status ENDORSEMENT_POLICY_FAILURE
          Failed to submit transaction: Error: Commit of transaction 8a06bccc8afd555efb4c1a70ac0ce1905c17f135061ca1ec525d760c0101118d failed on peer peer0.org1.example.com:7051 with status ENDORSEMENT_POLICY_FAILURE

          The logs from the peer docker containers are as follows:
          2020-06-19 10:01:14.584 UTC [committer.txvalidator] validateTx -> ERRO 0f2 Dispatch for transaction txId = 16c33a328f40e579577c1767b0b55054cf903c328cf1a236f1da0aafb1762099 returned error: validation of endorsement policy for chaincode fabcar in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

          Although, aforementioned methods are able to change the key-value in the private collection if executed successfully, it fails a lot many number of times too. I'm not sure why that happens.
          Appreciate any help!

          Thanks and regards.


          --

          Hritik Gupta

          B.Tech, Computer Science and Engineering

          Indian Institute of Technology

          Mandi, Himachal Pradesh – 175005

          +91-7838869482 | b16097@...



          Re: How to verify RAFT health in HLF version 1.4.4 #raft

          Senthil Nathan
           

          On Fri, Jun 19, 2020 at 9:38 AM shrugupt via lists.hyperledger.org <shrugupt=microsoft.com@...> wrote:
          Hi,

          Would really appreciate if anybody has any thought/suggestion regarding my query.

          Thanks,
          Shruti



          Inconsistent Private Data Collection Write operation

          Hritik Gupta <hritikgupta9@...>
           

          Hi all,

          I have a fabric 2.0 network with 2 orgs having 1 peer each (similar to test-network). I implemented a private data collection that persists in the off-chain DB of the peer of one of the orgs (Org1, as shown below)
          "name": "collectionMarblePrivateDetails", 
          "policy": "OR('Org1MSP.member')", 
          "requiredPeerCount": 0, 
          "maxPeerCount": 3, 
          "blockToLive": 0, 
          "memberOnlyRead": true, 
          "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member')" } 
          }
          I tried to change the value of the key in the private collection by invoking the relevant chaincode method from : (I'm using the submitTransaction method from the Contract class of fabric node-sdk) 
          1) an authorized peer
          2) an unauthorized peer after making the following change to the collection endorsement policy:
          "endorsementPolicy": { "signaturePolicy": "OR('Org1MSP.member'), OR('Org2MSP.member')" } 

          Although the above 2 operations work sometimes, but very inconsistently. It fails by giving the following endorsement policy error:

          2020-06-19T10:01:19.660Z - warn: [TransactionEventHandler]: strategyFail: commit failure for transaction "8a06bccc8afd555efb4c1a70ac0ce1905c17f135061ca1ec525d760c0101118d": Error: Commit of transaction 8a06bccc8afd555efb4c1a70ac0ce1905c17f135061ca1ec525d760c0101118d failed on peer peer0.org1.example.com:7051 with status ENDORSEMENT_POLICY_FAILURE
          Failed to submit transaction: Error: Commit of transaction 8a06bccc8afd555efb4c1a70ac0ce1905c17f135061ca1ec525d760c0101118d failed on peer peer0.org1.example.com:7051 with status ENDORSEMENT_POLICY_FAILURE

          The logs from the peer docker containers are as follows:
          2020-06-19 10:01:14.584 UTC [committer.txvalidator] validateTx -> ERRO 0f2 Dispatch for transaction txId = 16c33a328f40e579577c1767b0b55054cf903c328cf1a236f1da0aafb1762099 returned error: validation of endorsement policy for chaincode fabcar in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied

          Although, aforementioned methods are able to change the key-value in the private collection if executed successfully, it fails a lot many number of times too. I'm not sure why that happens.
          Appreciate any help!

          Thanks and regards.


          --

          Hritik Gupta

          B.Tech, Computer Science and Engineering

          Indian Institute of Technology

          Mandi, Himachal Pradesh – 175005

          +91-7838869482 | b16097@...



          Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 06/19/2020 #cal-notice

          fabric@lists.hyperledger.org Calendar <noreply@...>
           

          Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

          When:
          Friday, 19 June 2020
          6:00am to 7:00am
          (GMT+01: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


          Re: How to verify RAFT health in HLF version 1.4.4 #raft

          shrugupt@...
           

          Hi,

          Would really appreciate if anybody has any thought/suggestion regarding my query.

          Thanks,
          Shruti



          Documentation Workgroup: Agenda for Friday, 19 June

          Anthony O'Dowd <a_o-dowd@...>
           

          Hi All,

          We will hold the documentation workgroup calls this Friday -- with both an Eastern hemisphere and Western hemisphere call. Please feel free to come along, you're always very welcome.

          You can read about last week's calls at https://wiki.hyperledger.org/display/fabric/2020+06+12+DWG+Agenda You'll see significant minutes for both the Eastern and Western hemisphere calls, and recordings for both sessions. Our Eastern and Western hemisphere calls are very well attended at the moment -- thanks to all for your contributions and collaboration.

          Our Eastern hemisphere had excellent contributions from the Japanese and Malayalam working group teams.  We reviewed the recent updated documentation and discussed other additions to help new language translators get started. Tomorrow we will review the new i18n repository structure and how to use it;  it will allow us to converge many of our international language repositories.

          Our Western hemisphere call included the now regular V2.x status update from Pam and Joe on new content; keep up to date with these as we approach 2.2! There was an interesting discussion on the potential value of a forward looking Fabric architecture document, and a comprehensive update on Brazilian Portuguese language translation from Renato, who is ready to start to make content live to help boost wider collaboration.  David also shared some great interest in many other language translations that are starting: Arabic, Urdu, French, Spanish and more. Pam and Renato also discussed some recent pipfile updates; a small but important topic is you're building the documentation on Ubuntu.


          You can catch up with the full recordings and other sessions: https://wiki.hyperledger.org/display/fabric/Recordings

          See https://wiki.hyperledger.org/display/fabric/2020+06+19+DWG+Agenda for this week's agenda. Again, on the Eastern hemisphere call Aneena and her team will share progress including RTD builds, and PR mergin in the ML doc repo. On the Western hemisphere call, we also have a promising agenda.

          Please feel free to contribute using the wiki, including helping to build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+06+26+DWG+Agenda

          Thanks!

          Pam, Anthony,  Joe, Nik

          Meeting Details
          -------------
          Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

          The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

          Meeting 133A: Friday 19 June
                             1130 India Standard Time
                             1400 China Standard Time
                             1500 Japan Standard Time
                             1700 Australia Eastern Time
                             1400 Singapore Time
                             1100 Gulf Standard Time
                             1000 Moscow Standard Time
                             0700 Greenwich Mean Time
                             0800 Central European Time    

          Meeting 133B: Friday 19 June
                        1100 Central Daylight Time
                             1200 Eastern Daylight Time
                             0900 Pacific Daylight Time
                             1400 Brasil Time (BRT)
                             1600 Greenwich Mean Time
                             1700 Central European Time
                             1800 Moscow Standard Time

          Unless stated otherwise above:
          IBM United Kingdom Limited - Registered in England and Wales with number 741598.
          Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

          2901 - 2920 of 11416