Date   

Chaincode as an external service

David Enyeart
 

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart


Next Hyperledger Fabric Application Developer Community call -- this Thursday 25th June @ 3pm UTC time: 4pm UK, 11am ET, 8am PT

Paul O'Mahoney <mahoney@...>
 

dear Fabric Application Developer,


the next  Fabric Application Developer community call is: Thursday 25th June - 3pm UTC,  4pm UK time (+1), 11am ET (-5 hrs), 8am PT (-8 hrs)  - other time zones here.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Agendas%3A+Fabric+Application+Developer+Community+Call+Meetings  

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts, client apps using the SDKs, tutorials/demos etc -  eg using NodeJS/TypeScript, Java, Go etc etc) 
- helping app developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes


The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...


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


Re: Inconsistent Private Data Collection Write operation

David Enyeart
 

Thanks Adhav, I think you've assessed correctly. If the client gets two endorsements back it may randomly pick one of the responses to submit and apply both peer endorser signatures. In this case one of endorsed results is different and therefore one of the signatures won't match the results. Upon validation on each peer, the non-matching signature gets thrown out with warning "signature for identity 1 is invalid: The signature is invalid". Half the time org1 endorsement results will be passed, and half the time org2 endorsement results will be passed, hence the inconsistency. A well behaving client should detect the different endorsed results before submitting the transaction to orderer, so that it fails early rather than failing at validation time. I *think* Fabric Network can do that comparison, at least, it should be an option if not already.

As for the questions...

Question 1: I tried this field with both (true/false) value, giving the same result and it is expected. If anyone is able to read PDC then it beat the purpose of having private data. What is the purpose of having this field- "MemberReadOnly"?
                    If we make it false, do other members of org can read data? Does this field relate to signature policy?


Answer 1: PDC specifies which org PEERS are able to persist the private data, and request it from other peers if needed. The access control for CLIENTS may or may not align with that definition. Here's how the documentation explains MemberOnlyRead:
"a value of true indicates that peers automatically enforce that only clients belonging to one of the collection member organizations are allowed read access to private data. If a client from a non-member org attempts to execute a chaincode function that performs a read of a private data key, the chaincode invocation is terminated with an error. Utilize a value of false if you would like to encode more granular access control within individual chaincode functions."


Question2: If transactions require only one endorsement, does SDK(Fabric Network) send tx to all endorsing peers or only one?

Answer 2: With service discovery you can pass in a collection name, and it will return the minimum set of peers required to get an endorsement (one of either org's peers in this scenario). For using Fabric Network Node.js SDK with service discovery, see https://hyperledger.github.io/fabric-sdk-node/master/tutorial-discovery-fabric-network.html. I suspect in this scenario the collection name was not passed correctly to service discovery.


Question 3: If the client gets both endorsements (One is correct and one is wrong(peer from org2 could not read data)) from endorsing peer and client send tx(Having both endorsement response from both peer) to orderer and orderer to committing peer.                         Does Committing peer check only one endorsement or both?

Answer 3: As stated at the top, only one result is submitted, and both signatures are applied. If the endorsing peers signed over different data, then the signature that doesn't match gets thrown out as invalid. This leaves only one endorsement to be evaluated against the endorsement policy. In this scenario, the 'right' endorsement was being provided half the time.


Dave Enyeart


Re: Inconsistent Private Data Collection Write operation

Adhav Pavan
 

Hello Hritik,

1) As you mentioned about PDC configuration:

{
"name": "collectionCarPrivateDetails",
"policy": "OR('Org1MSP.member')",
"requiredPeerCount": 0,
"maxPeerCount": 3,
"blockToLive": 0,
"memberOnlyRead": true,
"memberOnlyWrite": false,
"endorsementPolicy": {
"signaturePolicy": "OR('Org1MSP.member', 'Org2MSP.member')"
}
}

By Default Chaincode policy is the Majority of Peer. But here you are overriding the endorsement Policy("OR('Org1MSP.member', 'Org2MSP.member')":any of the peers).

As per our discussion, you are getting private data before update it. But for org2 users have no access to PDC.

Whenever the client getting an endorsement response from the peer(org1), your transaction getting successful, and whenever the client getting an endorsement response from Peer(Org2), the transaction getting failed as peer form org 2 won't be able to read private data before putting private state.

I hope this helps you.

@David Enyeart ,  I have a couple of related doubts as below:

2) "memberOnlyRead": true,

Question 1: I tried this field with both (true/false) value, giving the same result and it is expected. If anyone is able to read PDC then it beat the purpose of having private data. What is the purpose of having this field- "MemberReadOnly"?
                    If we make it false, do other members of org can read data? Does this field relate to signature policy?

Question2: If transactions require only one endorsement, does SDK(Fabric Network) send tx to all endorsing peers or only one?

Question 3: If the client gets both endorsements (One is correct and one is wrong(peer from org2 could not read data)) from endorsing peer and client send tx(Having both endorsement response from both peer) to orderer and orderer to committing peer.                         Does Committing peer check only one endorsement or both?

Thanks in advance.



Heartfelt Regards,

Pavan Adhav
Blockchain Developer, Infinichains
phone:  8390114357
email:  pavan@...
------
Please excuse my brevity.


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

Right, if the chaincode only writes to the collection namespace, you only need to meet the collection endorsement policy.

Turning on full debug may provide a hint as to why a signature may be invalid:
FABRIC_LOGGING_SPEC=debug

Compare the debug processing of the valid and the invalid transaction.

Are you able to reproduce the problem when using the Test Network?
https://hyperledger-fabric.readthedocs.io/en/master/test_network.html


Dave Enyeart


Re: Inconsistent Private Data Collection Write operation

David Enyeart
 

Right, if the chaincode only writes to the collection namespace, you only need to meet the collection endorsement policy.

Turning on full debug may provide a hint as to why a signature may be invalid:
FABRIC_LOGGING_SPEC=debug

Compare the debug processing of the valid and the invalid transaction.

Are you able to reproduce the problem when using the Test Network?
https://hyperledger-fabric.readthedocs.io/en/master/test_network.html


Dave Enyeart


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

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

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

Organizer:
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

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. 

          2901 - 2920 of 11422