Does 503(import_only_enabled,api is not available) cause "Unable to connect to peer/orderer"

[uqix]

[varadgit]

@uqix That log message is noise we need to fix... that happens because there is some logic that connects to the deployer/operator that's not part of the open source and it is trying to connect to it...

the message you are seeing I believe is because of connectivity issues... perhaps grpc proxy is not setup in front of the peer? You could also look at the network traffic to see if there are not errors and pending requests.

[uqix]

But the Channels page works just fine, does it mean the connectivity is ok?

[varadgit]

Thanks for the datapoint... that helps... The fact that the version is populated generally means the operations endpoint is functional and the fact that you are able to see the channel means the grpc endpoint is functional.

Do you have more than one peer? If so, can you switch to the different peers and see if there is a difference?

I just setup a test network using the script and I am able to view the peer page

couple of things to check...

1. In Network tab, clear the content and visit the peer page and see what the request, response are. Any errors with deployer should be generally fine. I suspect we will see some failing request or pending request that might help.
   FYI... I have these errors (that are benign)
   

2. In the console tab see if there are any other errors

[uqix]

This is a little weird, the Peer page finally show details after waiting long enough, while the error message still exists:

[varadgit]

weird, indeed!

That message comes from the health check... if the healthcheck endpoint didn't respond in 30 seconds that message gets displayed.

Can you check this URL?
<peer_operations_url>/healthz

[uqix]

@varadgit

failed to ping to Docker daemon: cannot connect to Docker endpoint

But we use ccaas instead of Docker.

[varadgit]

@uqix This is because of this following line
https://github.com/hyperledger/fabric/blob/release-2.2/sampleconfig/core.yaml#L484

Can you try commenting that out and see if that helps?

[uqix]

We use bevel to deploy the network, no idea how to configure that😂

[varadgit]

You might want to open an issue and see how to configure it... Basically, the health endpoint relies on that setting and the Fabric default doesn't quite work for non-docker env.

[uqix]

I commented out endpoint: unix:///var/run/docker.sock in peer /etc/hyperledger/fabric/core.yaml, same error:

"failed to ping to Docker daemon: cannot connect to Docker endpoint"

[uqix]

All those ajax calls finished in less than 2 secs, why are the console waiting for so long to show peer details?

[varadgit]

@uqix Can you post the specific call that took time? Is it the call to get the list of components?

[uqix]

I guess because the console thinks peer is not ready yet (reason: "failed to ping to Docker daemon: cannot connect to Docker endpoint"), then it keeps polling healthz for some while until max retries used out or timed out, finally ProcessProposal endpoints are called to show peer details which is pretty fast, the long waiting time is taken for polling healthz not getting ProcessProposal.

[uqix]

I commented out endpoint: unix:///var/run/docker.sock in peer /etc/hyperledger/fabric/core.yaml, same error:

"failed to ping to Docker daemon: cannot connect to Docker endpoint"

My bad, was not aware the env var CORE_VM_ENDPOINT: unix:///host/var/run/docker.sock is passed by bevel to peer, removing it fixes this issue.

Thanks for your time.