Configuration parameters CA and address in peer.deliveryclient.addressOverrides area ignored when connecting to the orderers

[marianothiago]

Description

Fabric reads the values stored in core.yaml in the peer.deliveryclient.addressOverrides section, but when connecting to orderers through the connect method in the blocksprovider.go file (internal/pkg/peer/blocksprovider/blocksprovider.go) it is using the RandomEndpoint function (endpoint, err := d.Orderers.RandomEndpoint()) located in the connection.go file (internal/pkg/peer/orderers/connection.go) to set up the endpoint that will make the connection. However the RandomEndpoint function does not use the peer.deliveryclient.addressOverrides information read by Fabric.

Steps to reproduce

Create a fabric network with two organizations (each organization with a peer) and install the chaincode on the peers. Stop the peer from one of the organizations and change the Orderers TLS CA and the orderers TLS certificates. Start the organization's peer that was stopped. The peer willn't to connect to the orderers due to a TLS failure. Try using peer.deliveryclient.addressOverrides from core.yaml. Does not work.

PULL Rquest: #4510

[tock-ibm]

Can you provide evidence that what doesn't work is indeed Fabric's fault? (e.g. logs, or a branch with a test?)

The override endpoints are first loaded from the core yaml when the peer starts. Then when ever

Update(globalAddrs []string, orgs map[string]OrdererOrg)

is called, after a config TX, the source slice is rebuilt (this is the way the current config is applied as well after the peer starts). The sources slice is rebuilt by comparing the overrides to the addresses that come from the config block - globalAddrs or per org orgs . If an orderer override has the same address as one of the endpoints in the globalAddrs or orgs, it will be used instead of that specific address. This is the place to look for a bug, if there is one, in my opinion.

Moreover, using just one peer in an org is a bad idea, exactly because of situations like these. With more peers in an org you can restart the peer that has fallen behind with a snapshot from an up to date peer.

[marianothiago]

I understand that using a single peer is not a good option. But this situation that I mentioned is not the only one. I will exemplify with another situation: We created a Fabric network with 3 organizations. Some time later a new organization is added to the network. The Peers from this new organization will use block 0 to join the channel. And these peers will use the TLS certificate that is in block 0 to communicate with the orderers. However, if the ordering organization changed its TLS CA before these peers joined the channel, the communication between the new organization's peers and the orderers will fail, because they took the old TLS certificate from block 0. I will simulate this scenario I described and I will send the logs. In this case, we should use the peer.deliveryclient.addressOverrides property, but it didn't work.