The error has nothing to do with an expiredcertificate. I suggest you turn on the MSP loggingto debug level and then see why the policy wasn't satisfied. From: keerthycbe@... To:

Hi Yacov Thanks for your immediate reponse. We upgraded all our nodes to 1.4.6 with ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS flag set to true in orderer nodes. After this, we created a

The configuration of a channel is stored on the ledger, so semantically it is referred to as a "transaction", not just because it is stored on the ledger, but because the process for updating a

Hi Craig, Thanks. Indeed, this is the most advanced and convenient way of running Fabric in Kubernetes. I will work with all 1.4.x versions. Limitation is only for cryptogen tool for creating the

I have seen this - From - https://readthedocs.org/projects/hyperledger-fabric/downloads/pdf/latest/ Under 9.4 I cannot really understand that summary sentence, Is this referring to

It should work with 1.4.6, there is anintegration test that simulates this very

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere When: Friday, 6 March 2020, 6:00am to 7:00am, (GMT+00:00) Europe/London Where:https://zoom.us/j/6223336701 View

We have a production blockchain network using Fabric 1.4.0. Recently we came to know that all the org admin certs expired. We were trying to update the network to replace the admin certificate with

adding link to JIRA: https://jira.hyperledger.org/browse/FAB-17584

could this be prioritized please as it is a real blocker? why break something that used to work? thanks. From: Brett T Logan <Brett.T.Logan@...> Sent: Tuesday, March 3, 2020 8:19 PM To: siddjain@...

Hello, The documentation lists fabric 1.42 and 1.43 have you tested any of these with fabric2? This work looks really promising Thanks CHA From: fabric@... <fabric@...> on behalf of Eryargi, Hakan

Hi, Should I also define the CORE_PEER_GOSSIP_BOOTSTRAP variable? Besides the TLS handshake error, I also have this kind of logs: On peer0-org1: 2020-03-02 14:21:03.882 UTC [comm.grpc.server] 1 ->

While not a "known" issue, there was a likelihood that 2.0 changes broke devmode. We have an open item to test it amongst the dev team, and if not easily fixable to disable the codepath. Brett

so here's the latest issue we are having with Fabric using the release-2.0 branch. we start the peer with CORE_CHAINCODE_MODE=dev. we verify in debugger that userRunsCC is evaluating to true.

Hello, I've been attempting to establish a Fabric network utilizing the Blockchain Automation Framework. I'm currently deploying on a local Kubernetes cluster and am stuck at creation of the

if i add call i get From: Siddharth Jain <siddjain@...> Sent: Tuesday, March 3, 2020 11:00 AM To: fabric@... <fabric@...> Subject: Re: Fabric 2.0: commit readiness returns false but approvalformyorg

tried to debug this and found that its failing here: https://github.com/hyperledger/fabric/blob/release-2.0/core/chaincode/lifecycle/serializer.go#L291 if existingValue,ok := existingKeys[keyName];!ok

we have a network of 3 orgs Following the steps in https://hyperledger-fabric.readthedocs.io/en/release-2.0/build_network.html we executed approvalformyorg for each org. our command looked like

Both configtx.yaml files should work: https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml (Gets added to

hello, is there any ETA on updated fabric-samples corresponding to the 2.0 release? we looked at the configtx.yaml here: