Date   

Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 02/21/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 21 February 2020
4:00pm to 5:00pm
(GMT+00:00) Europe/London

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

Organizer:
a_o-dowd@... +441962816761

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


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

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 21 February 2020, 4:00pm to 5:00pm, (GMT+00:00) Europe/London

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

View Event

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

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


#fabric #fabric-questions #fabric-ca #fabric-ca-client #fabric #fabric-questions #fabric-ca #fabric-ca-client

chauhan.kartik25@...
 

I tried to register & enroll a user with the name 苏南 on Fabric-CA. The registration is getting successful but getting below error during enrollment.

error: [FabricCAClientService.js]: Failed to enroll 苏南, error:%o message=Enrollment failed with errors [[{"code":0,"message":"asn1: invalid UTF-8 string"}]], stack=Error: Enrollment failed with errors [[{"code":0,"message":"asn1: invalid UTF-8 string"}]]

The error clearly says that the letters are not supported in UTF-8 encoding. Can I change the default encoding while enrolling? If yes, which enoding scheme do I've to use to support Chinese letters?

Also, I tried to create a CSR and then a certificate using OpenSSL utility with Chinese letters in CN(CommonName). I was successfully able to create a certificate. So it seems like the issue is with the fabric-ca-client SDK. Is there any way I can add Chinese letters in a certificate while enrolling a user on Hyperledger Fabric?


Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 02/21/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

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

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

Organizer:
a_o-dowd@... +441962816761

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


Documentation Workgroup: Agenda for Friday, 21 Feb - Western hemisphere call only, no Eastern hemisphere call this week

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

Hello!

We will hold the documentation workgroup call this Friday, but there will only be a Western hemisphere call because Anthony is travelling, and without network access. Apologies to our Eastern hemisphere colleagues -- it will return next week! Thanks to everyone who attended last week's calls.

You can read all about last week's call at https://wiki.hyperledger.org/display/fabric/2020+02+14+DWG+Agenda It included a V2 status update from Pam and Joe, a review of the lifecycle tutorial,  and a review of the deployment guide.

Thanks to Joe for recording. Catch up: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week: https://wiki.hyperledger.org/display/fabric/2020+02+21+DWG+Agenda
Please feel free to contribute using the wiki, including helping to build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+02+28+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 116A: Friday 21 Feb
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 116B: Friday 14 Feb
              1100 Central Daylight Time
                   1200 Eastern Daylight Time
                   0900 Pacific Daylight Time
                   1400 Brasil Time (BRT)
                   1700 Greenwich Mean Time
                   1800 Central European Time
                   1900 Moscow Standard Tim
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


ANNOUNCEMENT: Hyperledger Fabric v1.4.5 is now available!

David Enyeart
 

Hyperledger Fabric and Fabric CA v1.4.5 are now available. See details of the included fixes in the release notes:
https://github.com/hyperledger/fabric/releases/tag/v1.4.5
https://github.com/hyperledger/fabric-ca/releases/tag/v1.4.5

We have received some questions about LTS release status. v1.4.x continues to be the LTS release and 3rd digit patch releases will continue to be made available on the v1.4.x release stream. Once the maintainers designate a v2.x minor release as the next LTS release, there will be an overlap period where maintenance fixes will continue to be provided for both releases, to allow existing production networks time to perform rolling upgrades.

Thanks to all the community members who reported an issue or provided a fix in the v1.4.5 release! Your efforts help to ensure that Fabric is well tuned for production workloads and operations.


Dave Enyeart


Chaincode commit ENDORSEMENT_POLICY_ERROR

indirajith
 

Hi all, 

My setup has two peer orgs and one orderer org. I am trying to commit a chaincode after getting approvals from two orgs. But the commit fails due to endorsement policy failure. I have gone through the logs. All the policies were successfully satisfied except Endorsement policy. 

When checking for endorsement policy, the logs doesn't seem to check(Verify/validate) the signature sets as it does for other policy evaluations. I could not pinpoint where the problem is.  In the log file, at line # 1082 the evaluation of endorsement policy starts. 

Peer logs are available: https://pastebin.com/0UXyLfRu

Final response for commit command: 
2020-02-20 12:05:39.815 UTC [chaincodeCmd] ClientWait -> INFO 04d txid [b5ce0e998412af7237dcb12962272ab3e9b02745db599720a8af217901ebd3ba] committed with status (ENDORSEMENT_POLICY_FAILURE) at peer1-org1.inuit.local:7051
2020-02-20 12:05:39.848 UTC [chaincodeCmd] ClientWait -> INFO 04e txid [b5ce0e998412af7237dcb12962272ab3e9b02745db599720a8af217901ebd3ba] committed with status (ENDORSEMENT_POLICY_FAILURE) at peer1-org2.inuit.local:7051
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

Could anyone shed some light on this issue?  Thanks in advance.
Regards,
Indirajith.


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 02/21/2020 6:00am-7:00am #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

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

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

View Event

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

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


Next Hyperledger Fabric Application Developer Community call - this Thursday (Feb 20th) is cancelled FYI

Paul O'Mahoney <mahoney@...>
 

hi all,

please note that the Community call will not run this Thursday - the next scheduled community call is Thursday 5th March..

best regards

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

mahoney@...

----- Forwarded by Paul O'Mahoney/UK/IBM on 19/02/2020 13:07 -----

From:        Paul O'Mahoney/UK/IBM
To:        fabric@...
Date:        17/02/2020 10:19
Subject:        Next Hyperledger Fabric Application Developer Community call - this Thursday,  Feb 20th @ 4pm UTC (4pm UK) - 11am ET, 8am PT



dear Fabric Application Developer,


the next  Fabric Application Developer community call is scheduled for this  Thursday Feb 20th @ 4pm UTC (4pm UK) - 11am ET (-5 hrs), 8am PT(-8 hrs) - see time zones.   It lasts approx 30-60 mins FYI.

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

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,  developing application clients, using the SDKs, tutorials/demos etc -  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


Proposal: add certificate expiration metrics

Konstantin Antipov
 

Hello everyone,

I'd like to propose new metric to monitor certificates expiration.

https://jira.hyperledger.org/browse/FAB-17497

Thanks for the "FAB-17000: Warn when certificates are about to expire", but this will not work in our case.
At a moment we have 4 different fabric environments, setted up at the different time and placed in different kubernetes clusters.
We need 100% accurate data when certificates are going to expire, better with different severities.

So, pretty simple (from my view) solution: every time any part of hyperledger fabric reads any certificate - it creates or updates metric with issuer and certificate CN as a labels and not_after as a value, in unixtime. Based on this data companies can setup any notification flow they need.


Kind regards,
Konstantin Antipov


Cancelled Event: Hyperledger Fabric Chaincode EVM - Wednesday, 19 February 2020 #cal-cancelled

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

Cancelled: Hyperledger Fabric Chaincode EVM

This event has been cancelled.

When:
Wednesday, 19 February 2020
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.backup

Organizer: Hyperledger Community Meetings linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0@...

Description:
Contact: Swetha Repakula srepaku@...

Topic: Hyperledger Fabric Chaincode EVM

Agenda: https://wiki.hyperledger.org/display/fabric/Meeting+Agenda

Join Zoom Meeting
https://zoom.us/j/6223336701

One tap mobile
+16699006833,,6223336701# US (San Jose)
+16465588656,,6223336701# US (New York)

Dial by your location
+1 669 900 6833 US (San Jose)
+1 646 558 8656 US (New York)
877 369 0926 US Toll-free
855 880 1246 US Toll-free
Meeting ID: 622 333 6701
Find your local number: https://zoom.us/u/acTtmm3MX4

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=VIEW&eid=NHAwNjJlaXNnc2I3Zmg4OXYyanY3cDlpcW1fUjIwMTkwNTE1VDE1MDAwMCBmYWJyaWNAbGlzdHMuaHlwZXJsZWRnZXIub3Jn&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19uZjl1NjRnOWs5cnZkOWY4dnA0dnVyMjNiMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tMzU5NTM3MDhlMTNlOTNhNDA1NDJmYjNjNTQ5OTc3NmQ0MzgzMjhjNg&ctz=America%2FLos_Angeles&hl=en&es=1.
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-


Re: registeruser.js - 1.4 v 2.0

Bret Harrison <beharrison@...>
 

With NodeSDK v2 beta.3 you will get the required admin `User` object instance for calling the `register` of fabric-ca-client from the fabric-network `Wallet` rather than from the underlying Client object instance of the Gateway.

const adminIdentity = await wallet.get('admin');
const provider = wallet.getProviderRegistry().getProvider(adminIdentity.type);
const adminUser = await provider.getUserContext(adminIdentity, 'admin’);
const secret = await ca.register({
affiliation: 'org1.department1',
enrollmentID: 'user1',
role: 'client'
}, adminUser);
const enrollment = await ca.enroll({
enrollmentID: 'user1',
enrollmentSecret: secret
});
const x509Identity = {
credentials: {
certificate: enrollment.certificate,
privateKey: enrollment.key.toBytes(),
},
mspId: 'Org1MSP',
type: 'X.509',
};
await wallet.put('user1', x509Identity);


Re: registeruser.js - 1.4 v 2.0

Trevor Lee Oakley <trevor@...>
 

I did more checks and it looks like fabric-ca-client was used before and now a Gateway is used. It also looks like getClient does not work with the instance of Gateway. This looks like a coding error unless the fabcar install has the wrong versions for the require('fabric-network').
 
I am unclear how this got to this level and somehow the docs need changing, a coding change, or a change in the install.
 
Trevor
 
 
 


From: "Trevor Lee Oakley" <trevor@...>
Sent: 18 February 2020 01:41
To: fabric@...
Subject: [Hyperledger Fabric] registeruser.js - 1.4 v 2.0
 
I email yesterday about an error in 2.0 and registeruser. I understand it is now under peer review. What is the recommended course of action to register a user in 2.0?
 
I checked 1.4 and saw the code is very different for registeruser. Can anyone explain why registeruser changed so much? I was thinking of using the 1.4 registeruser.js but I am unclear whether that would actually register the user and for the user to have all the required access.
 
Trevor Oakley 
 
 


registeruser.js - 1.4 v 2.0

Trevor Lee Oakley <trevor@...>
 

I email yesterday about an error in 2.0 and registeruser. I understand it is now under peer review. What is the recommended course of action to register a user in 2.0?
 
I checked 1.4 and saw the code is very different for registeruser. Can anyone explain why registeruser changed so much? I was thinking of using the 1.4 registeruser.js but I am unclear whether that would actually register the user and for the user to have all the required access.
 
Trevor Oakley 
 
 


Re: chaincode 2.0 problems

indirajith
 

Yes, I have defined Endorsement policies for my peer orgs. But not for the orderer org.
Endorsement:
            Type: Signature
            Rule: "OR('org1MSP.peer')"
Endorsement:
            Type: Signature
            Rule: "OR('org2MSP.peer')"
These are the endorsement policies for the orgs in my configtx.yaml. Don't they get endorsed when we commit the package? The peer orgs show both peers have successfully endorsed the transaction. 

Thank you verymuch for the response.
Kind regards,
Indirajith.


On Mon, 17 Feb 2020 at 16:12, Nikhil E Gupta <negupta@...> wrote:
Hi,

Your logs say zero of the endorsement sub-policies were defined. Did you define the endorsement sub policies in configtx.yaml for your organizations?




-----fabric@... wrote: -----
To: David Enyeart <enyeart@...>
From: "indirajith"
Sent by: fabric@...
Date: 02/17/2020 09:28AM
Cc: fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

Thank you David Enyeart,

As you have suggested, the problem was with credentials and I have fixed them. Now the problem is during the commit stage. Even though both Orgs approved the CC package and they both endorse the commit, it fails with ' (ENDORSEMENT_POLICY_FAILURE) '. The reason behind this is statebased validator fails. I don't know how to meet this state-based endorsement policy. The peer logs are as follows:

PEER1_ORG2

2020-02-17 13:40:32.589 UTC [lifecycle] CheckCommitReadiness -> INFO 0c6 Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [lifecycle] CommitChaincodeDefinition -> INFO 0c7 Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [endorser] callChaincode -> INFO 0c8 finished chaincode: _lifecycle duration: 24ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.596 UTC [comm.grpc.server] 1 -> INFO 0c9 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:37306 grpc.code=OK grpc.call_duration=26.626315ms
2020-02-17 13:40:34.650 UTC [gossip.privdata] StoreBlock -> INFO 0ca [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.651 UTC [vscc] Validate -> ERRO 0cb VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.651 UTC [committer.txvalidator] validateTx -> ERRO 0cc Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.651 UTC [committer.txvalidator] Validate -> INFO 0cd [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.652 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0ce Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.652 UTC [valimpl] preprocessProtoBlock -> WARN 0cf Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.713 UTC [kvledger] CommitLegacy -> INFO 0d0 [twoorgschannel] Committed block [15] with 1 transaction(s) in 61ms (state_validation=0ms block_and_pvtdata_commit=43ms state_commit=15ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0d1 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.599Z grpc.peer_address=192.168.176.103:37308 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125516881s

PEER2_ORG1

2020-02-17 13:40:32.563 UTC [lifecycle] CheckCommitReadiness -> INFO 09d Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [lifecycle] CommitChaincodeDefinition -> INFO 09e Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [endorser] callChaincode -> INFO 09f finished chaincode: _lifecycle duration: 80ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.567 UTC [comm.grpc.server] 1 -> INFO 0a0 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:56972 grpc.code=OK grpc.call_duration=82.034915ms
2020-02-17 13:40:34.657 UTC [gossip.privdata] StoreBlock -> INFO 0a1 [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.658 UTC [vscc] Validate -> ERRO 0a2 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.659 UTC [committer.txvalidator] validateTx -> ERRO 0a3 Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.659 UTC [committer.txvalidator] Validate -> INFO 0a4 [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.659 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0a5 Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.659 UTC [valimpl] preprocessProtoBlock -> WARN 0a6 Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.720 UTC [kvledger] CommitLegacy -> INFO 0a7 [twoorgschannel] Committed block [15] with 1 transaction(s) in 60ms (state_validation=0ms block_and_pvtdata_commit=41ms state_commit=17ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0a8 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.598Z grpc.peer_address=192.168.176.103:56974 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125825689s

Approvals:
{ "approvals": { "org1MSP": true, "org2MSP": true } }

Thank you.
Indirajith


On Thu, 6 Feb 2020 at 14:27, David Enyeart <enyeart@...> wrote:

This is not an issue with the submitting client credentials, it is an issue with the peer credentials not matching the org credentials in the channel config.

You must approve on a peer of your own org, before continuing on to the commit step (only the commit step is bound by the configured lifecycle endorsement policy).

So ENDORSEMENT_POLICY_FAILURE on approve step means that the credentials that the peer signed the endorsed approve transaction with, was not issued by that org's CA, as defined in the channel config.

It happens to me when I'm switching environments around. Double check the msp credentials specified in your peer's config against the org msp specified in your channel config transaction.

The msp locations for the org and peer are specified at:

https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml#L38
and
https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/core.yaml#L302

Note, the msp paths above are relative to the local FABRIC_CFG_PATH. This can get confusing... to better understand it, you can instead use a fully qualified msp path to ensure you are pointing to the correct credentials. e.g. to re-use cryptogen credentials from first-network sample, use:

<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/msp
and
<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp


Dave Enyeart

"indirajith" ---02/06/2020 02:51:39 AM---Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful insta

From: "indirajith" <indirajithv@...>
To:
Cc: fabric <fabric@...>
Date: 02/06/2020 02:51 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of  CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, 

` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at 
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` 

The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, 

` Error: proposal failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]` 
I tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? 

Thank you!
BR,
Indirajith.

On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
    Jason pointed out the problem:

    > You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`.

    opened FAB-17371 for this

    - J


    On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
    I'm using byfn w/o any modification

    - J

    On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
      Jay, how does your policy look like for both org and channel? Thanks.




      On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:
          I could reproduce this by approving the same definition twice (with same seq). It seems that the first approval is validated with /Channel/Application/Org1MSP/Endorsement, although the second is validate with /Channel/Application/LifecycleEndorsement

          - J

          On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote:
          Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found.

          1. Chaincode can be installed multiple times, if the chaincode package never changes, the returned package id will be the same. No errors.
          2. Command chaincode lifecycle approveformyorg behaves like this (at least from what I can figure):
          a.) one peer in the org can only approve the chaincode one time
          b.) the other peer in the org can also approve the chaincode but the sequence number has to increase by 1, this is after chaincode has been committed.
          c.) once the chaincode gets approved by a peer, that peer can not approve it the 2nd time. If you try the 2nd time, it will give you the same error like below:

          2020-01-08 16:31:53.754 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [af84dab09c428471a87aad3e9f921b8f876ecdc69b6b0b05fdf42d621cd3e31a] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          The behavior at 2 is a bit different from what David suggested earlier, I wonder if I misunderstood David's point. My endorsement policy is using the Majority.

          Thanks so much for your response.


          Tong Li
          IBM Open Technology

          Inactive hide details for"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib

          From: "Nikhil Gupta" <negupta@...>
          To: "David Enyeart" <enyeart@...>
          Cc: "Tong Li" <litong01@...>, fabric@...
          Date: 01/08/2020 08:53 AM
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...




          The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip.

          The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved.



          -----fabric@... wrote: -----
          To: "Tong Li" <litong01@...>
          From: "David Enyeart"
          Sent by: fabric@...
          Date: 01/08/2020 12:28AM
          Cc: fabric@...
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

          1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

          2. Your LifecycleEndorsement policy is:

          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          This will require the chaincode commit to be endorsed by both orgs (majority of '2' is '2'). I suspect you only sent the chaincode commit to one of the org peers. Alternatively, you could update your config to indicate that either org can endorse the commit of a new chaincode, e.g.:

          LifecycleEndorsement:
          Type: Signature
          Rule: "OR('org0examplecom.admin.peer','org1examplecom.peer')"


          Dave Enyeart

          Inactive hide details for"Tong Li" ---01/07/2020 11:19:18 PM---Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincod

          From: "Tong Li" <litong01@...>
          To: fabric@...
          Date: 01/07/2020 11:19 PM
          Subject: [EXTERNAL] [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...





          Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

          1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

          {
          "approvals": {
          "org0examplecom": true,
          "org1examplecom": true
          }
          }

          That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

          peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
          2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
          2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

          2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

          ---
          Organizations:
          - &examplecom
          Name: examplecom
          ID: examplecom
          MSPDir: keyfiles/ordererOrganizations/example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Writers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Admins:
          Type: Signature
          Rule: "OR('examplecom.admin')"
          - &org0examplecom
          Name: org0examplecom
          ID: org0examplecom
          MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org0examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org0examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org0.example.com
          Port: 7051
          - Host: peer2.org0.example.com
          Port: 7051
          - &org1examplecom
          Name: org1examplecom
          ID: org1examplecom
          MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org1examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org1examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org1.example.com
          Port: 7051
          - Host: peer2.org1.example.com
          Port: 7051

          Capabilities:
          Channel: &ChannelCapabilities
          V2_0: true

          Orderer: &OrdererCapabilities
          V2_0: true

          Application: &ApplicationCapabilities
          V2_0: true

          Application: &ApplicationDefaults
          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"
          Endorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          Capabilities:
          <<: *ApplicationCapabilities

          Orderer: &OrdererDefaults
          OrdererType: etcdraft

          Addresses:
          - orderer1.example.com:7050
          - orderer2.example.com:7050
          - orderer3.example.com:7050

          BatchTimeout: 2s

          BatchSize:
          MaxMessageCount: 10
          AbsoluteMaxBytes: 99 MB
          PreferredMaxBytes: 512 KB

          EtcdRaft:
          Consenters:
          - Host: orderer1.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          - Host: orderer2.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          - Host: orderer3.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          BlockValidation:
          Type: ImplicitMeta
          Rule: "ANY Writers"

          Channel: &ChannelDefaults
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"

          Capabilities:
          <<: *ChannelCapabilities

          Profiles:
          OrgChannel:
          Consortium: SampleConsortium
          <<: *ChannelDefaults
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - *org0examplecom
          - *org1examplecom
          Capabilities:
          <<: *ApplicationCapabilities

          OrdererGenesis:
          <<: *ChannelDefaults
          Capabilities:
          <<: *ChannelCapabilities
          Orderer:
          <<: *OrdererDefaults
          Organizations:
          - *examplecom
          Capabilities:
          <<: *OrdererCapabilities
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - <<: *examplecom
          Consortiums:
          SampleConsortium:
          Organizations:
          - *org0examplecom
          - *org1examplecom


          Tong Li
          IBM Open Technology










Re: chaincode 2.0 problems

Nikhil Gupta
 

Hi,

Your logs say zero of the endorsement sub-policies were defined. Did you define the endorsement sub policies in configtx.yaml for your organizations?




-----fabric@... wrote: -----
To: David Enyeart <enyeart@...>
From: "indirajith"
Sent by: fabric@...
Date: 02/17/2020 09:28AM
Cc: fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

Thank you David Enyeart,

As you have suggested, the problem was with credentials and I have fixed them. Now the problem is during the commit stage. Even though both Orgs approved the CC package and they both endorse the commit, it fails with ' (ENDORSEMENT_POLICY_FAILURE) '. The reason behind this is statebased validator fails. I don't know how to meet this state-based endorsement policy. The peer logs are as follows:

PEER1_ORG2

2020-02-17 13:40:32.589 UTC [lifecycle] CheckCommitReadiness -> INFO 0c6 Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [lifecycle] CommitChaincodeDefinition -> INFO 0c7 Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [endorser] callChaincode -> INFO 0c8 finished chaincode: _lifecycle duration: 24ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.596 UTC [comm.grpc.server] 1 -> INFO 0c9 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:37306 grpc.code=OK grpc.call_duration=26.626315ms
2020-02-17 13:40:34.650 UTC [gossip.privdata] StoreBlock -> INFO 0ca [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.651 UTC [vscc] Validate -> ERRO 0cb VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.651 UTC [committer.txvalidator] validateTx -> ERRO 0cc Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.651 UTC [committer.txvalidator] Validate -> INFO 0cd [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.652 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0ce Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.652 UTC [valimpl] preprocessProtoBlock -> WARN 0cf Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.713 UTC [kvledger] CommitLegacy -> INFO 0d0 [twoorgschannel] Committed block [15] with 1 transaction(s) in 61ms (state_validation=0ms block_and_pvtdata_commit=43ms state_commit=15ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0d1 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.599Z grpc.peer_address=192.168.176.103:37308 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125516881s

PEER2_ORG1

2020-02-17 13:40:32.563 UTC [lifecycle] CheckCommitReadiness -> INFO 09d Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [lifecycle] CommitChaincodeDefinition -> INFO 09e Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [endorser] callChaincode -> INFO 09f finished chaincode: _lifecycle duration: 80ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.567 UTC [comm.grpc.server] 1 -> INFO 0a0 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:56972 grpc.code=OK grpc.call_duration=82.034915ms
2020-02-17 13:40:34.657 UTC [gossip.privdata] StoreBlock -> INFO 0a1 [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.658 UTC [vscc] Validate -> ERRO 0a2 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.659 UTC [committer.txvalidator] validateTx -> ERRO 0a3 Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.659 UTC [committer.txvalidator] Validate -> INFO 0a4 [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.659 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0a5 Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.659 UTC [valimpl] preprocessProtoBlock -> WARN 0a6 Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.720 UTC [kvledger] CommitLegacy -> INFO 0a7 [twoorgschannel] Committed block [15] with 1 transaction(s) in 60ms (state_validation=0ms block_and_pvtdata_commit=41ms state_commit=17ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0a8 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.598Z grpc.peer_address=192.168.176.103:56974 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125825689s

Approvals:
{ "approvals": { "org1MSP": true, "org2MSP": true } }

Thank you.
Indirajith


On Thu, 6 Feb 2020 at 14:27, David Enyeart <enyeart@...> wrote:

This is not an issue with the submitting client credentials, it is an issue with the peer credentials not matching the org credentials in the channel config.

You must approve on a peer of your own org, before continuing on to the commit step (only the commit step is bound by the configured lifecycle endorsement policy).

So ENDORSEMENT_POLICY_FAILURE on approve step means that the credentials that the peer signed the endorsed approve transaction with, was not issued by that org's CA, as defined in the channel config.

It happens to me when I'm switching environments around. Double check the msp credentials specified in your peer's config against the org msp specified in your channel config transaction.

The msp locations for the org and peer are specified at:

https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml#L38
and
https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/core.yaml#L302

Note, the msp paths above are relative to the local FABRIC_CFG_PATH. This can get confusing... to better understand it, you can instead use a fully qualified msp path to ensure you are pointing to the correct credentials. e.g. to re-use cryptogen credentials from first-network sample, use:

<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/msp
and
<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp


Dave Enyeart

"indirajith" ---02/06/2020 02:51:39 AM---Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful insta

From: "indirajith" <indirajithv@...>
To:
Cc: fabric <fabric@...>
Date: 02/06/2020 02:51 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of  CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, 

` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at 
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` 

The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, 

` Error: proposal failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]` 
I tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? 

Thank you!
BR,
Indirajith.

On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
    Jason pointed out the problem:

    > You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`.

    opened FAB-17371 for this

    - J


    On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
    I'm using byfn w/o any modification

    - J

    On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
      Jay, how does your policy look like for both org and channel? Thanks.




      On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:
          I could reproduce this by approving the same definition twice (with same seq). It seems that the first approval is validated with /Channel/Application/Org1MSP/Endorsement, although the second is validate with /Channel/Application/LifecycleEndorsement

          - J

          On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote:
          Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found.

          1. Chaincode can be installed multiple times, if the chaincode package never changes, the returned package id will be the same. No errors.
          2. Command chaincode lifecycle approveformyorg behaves like this (at least from what I can figure):
          a.) one peer in the org can only approve the chaincode one time
          b.) the other peer in the org can also approve the chaincode but the sequence number has to increase by 1, this is after chaincode has been committed.
          c.) once the chaincode gets approved by a peer, that peer can not approve it the 2nd time. If you try the 2nd time, it will give you the same error like below:

          2020-01-08 16:31:53.754 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [af84dab09c428471a87aad3e9f921b8f876ecdc69b6b0b05fdf42d621cd3e31a] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          The behavior at 2 is a bit different from what David suggested earlier, I wonder if I misunderstood David's point. My endorsement policy is using the Majority.

          Thanks so much for your response.


          Tong Li
          IBM Open Technology

          Inactive hide details for"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib

          From: "Nikhil Gupta" <negupta@...>
          To: "David Enyeart" <enyeart@...>
          Cc: "Tong Li" <litong01@...>, fabric@...
          Date: 01/08/2020 08:53 AM
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...




          The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip.

          The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved.



          -----fabric@... wrote: -----
          To: "Tong Li" <litong01@...>
          From: "David Enyeart"
          Sent by: fabric@...
          Date: 01/08/2020 12:28AM
          Cc: fabric@...
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

          1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

          2. Your LifecycleEndorsement policy is:

          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          This will require the chaincode commit to be endorsed by both orgs (majority of '2' is '2'). I suspect you only sent the chaincode commit to one of the org peers. Alternatively, you could update your config to indicate that either org can endorse the commit of a new chaincode, e.g.:

          LifecycleEndorsement:
          Type: Signature
          Rule: "OR('org0examplecom.admin.peer','org1examplecom.peer')"


          Dave Enyeart

          Inactive hide details for"Tong Li" ---01/07/2020 11:19:18 PM---Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincod

          From: "Tong Li" <litong01@...>
          To: fabric@...
          Date: 01/07/2020 11:19 PM
          Subject: [EXTERNAL] [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...





          Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

          1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

          {
          "approvals": {
          "org0examplecom": true,
          "org1examplecom": true
          }
          }

          That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

          peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
          2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
          2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

          2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

          ---
          Organizations:
          - &examplecom
          Name: examplecom
          ID: examplecom
          MSPDir: keyfiles/ordererOrganizations/example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Writers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Admins:
          Type: Signature
          Rule: "OR('examplecom.admin')"
          - &org0examplecom
          Name: org0examplecom
          ID: org0examplecom
          MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org0examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org0examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org0.example.com
          Port: 7051
          - Host: peer2.org0.example.com
          Port: 7051
          - &org1examplecom
          Name: org1examplecom
          ID: org1examplecom
          MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org1examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org1examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org1.example.com
          Port: 7051
          - Host: peer2.org1.example.com
          Port: 7051

          Capabilities:
          Channel: &ChannelCapabilities
          V2_0: true

          Orderer: &OrdererCapabilities
          V2_0: true

          Application: &ApplicationCapabilities
          V2_0: true

          Application: &ApplicationDefaults
          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"
          Endorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          Capabilities:
          <<: *ApplicationCapabilities

          Orderer: &OrdererDefaults
          OrdererType: etcdraft

          Addresses:
          - orderer1.example.com:7050
          - orderer2.example.com:7050
          - orderer3.example.com:7050

          BatchTimeout: 2s

          BatchSize:
          MaxMessageCount: 10
          AbsoluteMaxBytes: 99 MB
          PreferredMaxBytes: 512 KB

          EtcdRaft:
          Consenters:
          - Host: orderer1.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          - Host: orderer2.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          - Host: orderer3.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          BlockValidation:
          Type: ImplicitMeta
          Rule: "ANY Writers"

          Channel: &ChannelDefaults
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"

          Capabilities:
          <<: *ChannelCapabilities

          Profiles:
          OrgChannel:
          Consortium: SampleConsortium
          <<: *ChannelDefaults
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - *org0examplecom
          - *org1examplecom
          Capabilities:
          <<: *ApplicationCapabilities

          OrdererGenesis:
          <<: *ChannelDefaults
          Capabilities:
          <<: *ChannelCapabilities
          Orderer:
          <<: *OrdererDefaults
          Organizations:
          - *examplecom
          Capabilities:
          <<: *OrdererCapabilities
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - <<: *examplecom
          Consortiums:
          SampleConsortium:
          Organizations:
          - *org0examplecom
          - *org1examplecom


          Tong Li
          IBM Open Technology










Re: chaincode 2.0 problems

indirajith
 

Thank you David Enyeart,

As you have suggested, the problem was with credentials and I have fixed them. Now the problem is during the commit stage. Even though both Orgs approved the CC package and they both endorse the commit, it fails with ' (ENDORSEMENT_POLICY_FAILURE) '. The reason behind this is statebased validator fails. I don't know how to meet this state-based endorsement policy. The peer logs are as follows:

PEER1_ORG2

2020-02-17 13:40:32.589 UTC [lifecycle] CheckCommitReadiness -> INFO 0c6 Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [lifecycle] CommitChaincodeDefinition -> INFO 0c7 Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [endorser] callChaincode -> INFO 0c8 finished chaincode: _lifecycle duration: 24ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.596 UTC [comm.grpc.server] 1 -> INFO 0c9 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:37306 grpc.code=OK grpc.call_duration=26.626315ms
2020-02-17 13:40:34.650 UTC [gossip.privdata] StoreBlock -> INFO 0ca [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.651 UTC [vscc] Validate -> ERRO 0cb VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.651 UTC [committer.txvalidator] validateTx -> ERRO 0cc Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.651 UTC [committer.txvalidator] Validate -> INFO 0cd [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.652 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0ce Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.652 UTC [valimpl] preprocessProtoBlock -> WARN 0cf Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.713 UTC [kvledger] CommitLegacy -> INFO 0d0 [twoorgschannel] Committed block [15] with 1 transaction(s) in 61ms (state_validation=0ms block_and_pvtdata_commit=43ms state_commit=15ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0d1 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.599Z grpc.peer_address=192.168.176.103:37308 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125516881s

PEER2_ORG1

2020-02-17 13:40:32.563 UTC [lifecycle] CheckCommitReadiness -> INFO 09d Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [lifecycle] CommitChaincodeDefinition -> INFO 09e Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [endorser] callChaincode -> INFO 09f finished chaincode: _lifecycle duration: 80ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.567 UTC [comm.grpc.server] 1 -> INFO 0a0 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:56972 grpc.code=OK grpc.call_duration=82.034915ms
2020-02-17 13:40:34.657 UTC [gossip.privdata] StoreBlock -> INFO 0a1 [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.658 UTC [vscc] Validate -> ERRO 0a2 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.659 UTC [committer.txvalidator] validateTx -> ERRO 0a3 Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle 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
2020-02-17 13:40:34.659 UTC [committer.txvalidator] Validate -> INFO 0a4 [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.659 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0a5 Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.659 UTC [valimpl] preprocessProtoBlock -> WARN 0a6 Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.720 UTC [kvledger] CommitLegacy -> INFO 0a7 [twoorgschannel] Committed block [15] with 1 transaction(s) in 60ms (state_validation=0ms block_and_pvtdata_commit=41ms state_commit=17ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0a8 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.598Z grpc.peer_address=192.168.176.103:56974 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125825689s

Approvals:
{ "approvals": { "org1MSP": true, "org2MSP": true } }

Thank you.
Indirajith


On Thu, 6 Feb 2020 at 14:27, David Enyeart <enyeart@...> wrote:

This is not an issue with the submitting client credentials, it is an issue with the peer credentials not matching the org credentials in the channel config.

You must approve on a peer of your own org, before continuing on to the commit step (only the commit step is bound by the configured lifecycle endorsement policy).

So ENDORSEMENT_POLICY_FAILURE on approve step means that the credentials that the peer signed the endorsed approve transaction with, was not issued by that org's CA, as defined in the channel config.

It happens to me when I'm switching environments around. Double check the msp credentials specified in your peer's config against the org msp specified in your channel config transaction.

The msp locations for the org and peer are specified at:

https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml#L38
and
https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/core.yaml#L302

Note, the msp paths above are relative to the local FABRIC_CFG_PATH. This can get confusing... to better understand it, you can instead use a fully qualified msp path to ensure you are pointing to the correct credentials. e.g. to re-use cryptogen credentials from first-network sample, use:

<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/msp
and
<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp


Dave Enyeart

"indirajith" ---02/06/2020 02:51:39 AM---Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful insta

From: "indirajith" <indirajithv@...>
To:
Cc: fabric <fabric@...>
Date: 02/06/2020 02:51 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of  CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, 

` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at 
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` 

The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, 

` Error: proposal failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]` 
I tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? 

Thank you!
BR,
Indirajith.

On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
    Jason pointed out the problem:

    > You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`.

    opened FAB-17371 for this

    - J


    On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
    I'm using byfn w/o any modification

    - J

    On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
      Jay, how does your policy look like for both org and channel? Thanks.




      On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:
          I could reproduce this by approving the same definition twice (with same seq). It seems that the first approval is validated with /Channel/Application/Org1MSP/Endorsement, although the second is validate with /Channel/Application/LifecycleEndorsement

          - J

          On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote:
          Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found.

          1. Chaincode can be installed multiple times, if the chaincode package never changes, the returned package id will be the same. No errors.
          2. Command chaincode lifecycle approveformyorg behaves like this (at least from what I can figure):
          a.) one peer in the org can only approve the chaincode one time
          b.) the other peer in the org can also approve the chaincode but the sequence number has to increase by 1, this is after chaincode has been committed.
          c.) once the chaincode gets approved by a peer, that peer can not approve it the 2nd time. If you try the 2nd time, it will give you the same error like below:

          2020-01-08 16:31:53.754 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [af84dab09c428471a87aad3e9f921b8f876ecdc69b6b0b05fdf42d621cd3e31a] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          The behavior at 2 is a bit different from what David suggested earlier, I wonder if I misunderstood David's point. My endorsement policy is using the Majority.

          Thanks so much for your response.


          Tong Li
          IBM Open Technology

          Inactive hide details for"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib

          From: "Nikhil Gupta" <negupta@...>
          To: "David Enyeart" <enyeart@...>
          Cc: "Tong Li" <litong01@...>, fabric@...
          Date: 01/08/2020 08:53 AM
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...




          The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip.

          The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved.



          -----fabric@... wrote: -----
          To: "Tong Li" <litong01@...>
          From: "David Enyeart"
          Sent by: fabric@...
          Date: 01/08/2020 12:28AM
          Cc: fabric@...
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

          1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

          2. Your LifecycleEndorsement policy is:

          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          This will require the chaincode commit to be endorsed by both orgs (majority of '2' is '2'). I suspect you only sent the chaincode commit to one of the org peers. Alternatively, you could update your config to indicate that either org can endorse the commit of a new chaincode, e.g.:

          LifecycleEndorsement:
          Type: Signature
          Rule: "OR('org0examplecom.admin.peer','org1examplecom.peer')"


          Dave Enyeart

          Inactive hide details for"Tong Li" ---01/07/2020 11:19:18 PM---Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincod

          From: "Tong Li" <litong01@...>
          To: fabric@...
          Date: 01/07/2020 11:19 PM
          Subject: [EXTERNAL] [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...





          Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

          1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

          {
          "approvals": {
          "org0examplecom": true,
          "org1examplecom": true
          }
          }

          That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

          peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
          2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
          2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

          2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

          ---
          Organizations:
          - &examplecom
          Name: examplecom
          ID: examplecom
          MSPDir: keyfiles/ordererOrganizations/example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Writers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Admins:
          Type: Signature
          Rule: "OR('examplecom.admin')"
          - &org0examplecom
          Name: org0examplecom
          ID: org0examplecom
          MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org0examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org0examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org0.example.com
          Port: 7051
          - Host: peer2.org0.example.com
          Port: 7051
          - &org1examplecom
          Name: org1examplecom
          ID: org1examplecom
          MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org1examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org1examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org1.example.com
          Port: 7051
          - Host: peer2.org1.example.com
          Port: 7051

          Capabilities:
          Channel: &ChannelCapabilities
          V2_0: true

          Orderer: &OrdererCapabilities
          V2_0: true

          Application: &ApplicationCapabilities
          V2_0: true

          Application: &ApplicationDefaults
          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"
          Endorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          Capabilities:
          <<: *ApplicationCapabilities

          Orderer: &OrdererDefaults
          OrdererType: etcdraft

          Addresses:
          - orderer1.example.com:7050
          - orderer2.example.com:7050
          - orderer3.example.com:7050

          BatchTimeout: 2s

          BatchSize:
          MaxMessageCount: 10
          AbsoluteMaxBytes: 99 MB
          PreferredMaxBytes: 512 KB

          EtcdRaft:
          Consenters:
          - Host: orderer1.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          - Host: orderer2.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          - Host: orderer3.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          BlockValidation:
          Type: ImplicitMeta
          Rule: "ANY Writers"

          Channel: &ChannelDefaults
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"

          Capabilities:
          <<: *ChannelCapabilities

          Profiles:
          OrgChannel:
          Consortium: SampleConsortium
          <<: *ChannelDefaults
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - *org0examplecom
          - *org1examplecom
          Capabilities:
          <<: *ApplicationCapabilities

          OrdererGenesis:
          <<: *ChannelDefaults
          Capabilities:
          <<: *ChannelCapabilities
          Orderer:
          <<: *OrdererDefaults
          Organizations:
          - *examplecom
          Capabilities:
          <<: *OrdererCapabilities
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - <<: *examplecom
          Consortiums:
          SampleConsortium:
          Organizations:
          - *org0examplecom
          - *org1examplecom


          Tong Li
          IBM Open Technology









Re: 7.1.3 of the Tutorial (page 188) v2.0.0 pdf

Trevor Lee Oakley <trevor@...>
 

Is there a work around for this?

--------------Original Message--------------

From: "Bret Harrison" <beharrison@...>
Sent: Monday, February 17, 2020 08:37:AM
To: fabric@...
Subject: Re: [Hyperledger Fabric] 7.1.3 of the Tutorial (page 188) v2.0.0
pdf

We have a PR in review to fix the following issue
Failed to register user "user1": TypeError: gateway.getClient is not a
function

See https://github.com/hyperledger/fabric-samples/pull/117


Re: Proposal : Hyperledger Fabric block archiving

nekia <atsushin@...>
 

Hi,

I figured out that it's quite difficult to estimate maximum size in advance to align metadata size on each orderer. So we've decided to change to handle archive data at block level, not at blockfile level. By managing archived data at block level, we can avoid the following issues:
  • The layout of blockfile with same suffix is not always identical among peers in an organization
  • Because of this variance of the layout, each peer can't get access to archived data by using original block location info recorded in block index DB
I've put together overview of the new approach in the following slide.
HLF Block Archiving - Google Slides

In the feedbacks we got in this thread, implementing separately from fabric core has been mentioned several times. We have not been able to offer this feature as a pluggable module for ledger layer of fabric so far. One of the main reasons of it is that we need to hook the local file access when reading block data from local file system.

Do you think this project can compensate or coexist the functionality offered by 'ledger checkpoint and pruning' feature which is planned to be added to v2.x?

Cheeers,
Atsushi


Re: 7.1.3 of the Tutorial (page 188) v2.0.0 pdf

Bret Harrison <beharrison@...>
 

We have a PR in review to fix the following issue
Failed to register user "user1": TypeError: gateway.getClient is not a function

3681 - 3700 of 11416