I do not think you’d benefit by using different root CA’s for orderer and peer of the same org. Each org already need 2 root CA’s, one for signing cert, the other for TLS. If you double that,

On 11/25/19 6:09 PM, David Enyeart wrote: Are there separate maintainer pools for different fabric-* repos? If so, I can understand the argument, coming from a world

Our intent has been to split Fabric docs into its own repository after the transition to GitHub and Azure Pipelines. We only have one more repository to switch over (fabric-test), then will proceed

The transition to GitHub for source control management, and Azure Pipelines for CI, is now complete for all Fabric development repositories. The final repository to shift will be fabric-test in early

> and wasrecently recognized as a Hyperledgersignificant contributor. Just for the record.... only IBMerscan access this link.... From: "Pam Andrejko"<pama@...> To:

All, I would like to nominate two new Documentation maintainers for the Hyperledger Fabric project. They are Chris Gabriel (Hyperchain Labs) and Joe Alewine (IBM). Chris has been an instrumental

Hey Atsushi, one thing I noticed while skimming thecode, is that while you send the ArchivedBlockFileMsg via gossip, you arenot ensuring it is eventually propagated to peers successfully. This means

Hi Atsushi, Thanks for your proposal and at high level the objective makes sense to me and below is my high level observations that you may want to consider. First, the fundamental assumption that

Private VLAN/VPN, or do a proper public IP p2p setup w/o docker swarm. Again, docker swarm and k8s are great for distributed microservices and big load balanced, asymmetrical

I highly suggest that you look into cello ansible agent to deploy your network onto k8s environment. Here is the doc on how to do that. hyperledger/cello hyperledger/cello Operating System for

Thanks Tong. We are currently using Docker swarm as a method of deploying a Fabric network across multiple hosts. However, this solution can only be properly applied to hosts inside the same LAN.

dear Fabric ApplicationDeveloper, the next FabricApplication Developer community call is scheduled for this ThursdayNov 28th @ 4pm UTC (4pm UK) - 11am ET (-5 hrs), 8am PT(-8 hrs)- seetime zones. It

Why is it a "best practice" to have different CAs for peers and for orderers? What potential problems is this solving over having a single CA for both? Regards, Todd

Yueming, From the description you gave and Joe's explanation, you should have two CAs instead one of to issue the certificates for both MSPs (One for org1MSP and one for org1OrdererMSP). Joe explained

As I understand it, each org is similar to a real-world business entity, and should have its own CA. Each org may or may not own an orderer node. If an org contributes both peer and orderer nodes,

Yes, as I keep saying, your peers and ordering nodes should belong to different Fabric organizations. If there are subgroupings within a large entity like a bank, this separation should still happen

Thanks Joe, So it is technically feasible but not recommended for decentralization purposes, right? I could imagine a use case where we don't have such a large organization with different arms like

Harris, This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business

Hi Joe and Jean, Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers. So instead of creating new organizations for each orderer

Joe, Thank you very much for your great explanation which was exactly the kind of insights I was looking for. Unless I'm wrong (if so correct me please), the illustration I made in my previous post