I’m writing a POC which runs an IPFS node and also an instance of IPFS Cluster. I can successfully start the node and the cluster. The problem is that the IPFS API only returns 404 RPC endpoint doesn’t exist. I used the functions serveHTTPApi and serveHTTPGateway from the daemon source code. Both the API and Gateway starts up, it’s possible to see it in the open ports of my pc
main 14281 mypc 24u IPv4 0x9192403e3001e1dd 0t0 TCP *:4001 (LISTEN)
main 14281 mypc 26u IPv6 0x9192403e2ee8bd3d 0t0 TCP *:4001 (LISTEN)
main 14281 mypc 43u IPv4 0x9192403e2e8e856d 0t0 TCP localhost:5001 (LISTEN)
main 14281 mypc 45u IPv4 0x9192403e2ec91655 0t0 TCP localhost:8080 (LISTEN)
IPFS node is running API server listening on /ip4/127.0.0.1/tcp/5001 WebUI: http://127.0.0.1:5001/webui Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
I’m also able to access the WebUI but with the message Failed to connect to the API. Using curl returns 404 no any endpoint too.
The cluster throws this errors:
2020-06-26T20:30:19.908+0100 ERROR ipfshttp IPFS request unsuccessful (repo/stat?size-only=true). Code 404. Body: 404 page not found
2020-06-26T20:30:19.908+0100 ERROR p2p-gorpc IPFS request unsuccessful (repo/stat?size-only=true). Code 404. Body: 404 page not found
2020-06-26T20:30:19.908+0100 ERROR diskinfo IPFS request unsuccessful (repo/stat?size-only=true). Code 404. Body: 404 page not found
Yes I’m using the go-ipfs library to initialize my own node based on this example and a custom build of the ipfs-cluster in the same code. Basically I first start the IPFS node and then if succeed starts the ipfs cluster and connects to 127.0.0.1:5001.
To initialize the IPFS node API I toke a look at the IPFS daemon source code and used both the serveHTTPApi and serveHTTPGateway functions to expose the API and Gateway Ports. But I guess I might be missing something because indeed the ports were open, but the API does not expose any endpoint.
Well, your API 404-ing means request handlers might be missing. I am not sure what needs to be done to run the gateway by hand (doesn’t the example does it by itself?). If you are binding both ipfs and ipfs-cluster in a single binary, you could skip using the http api altogether though and add a new connector implementation directly that uses the ipfs core API directly (related https://github.com/textileio/go-textile/pull/831/files#diff-5d87e68af33532d3c963b1dc695da064R1)
@hector Just managed to make it work with a new connector. Only needed to rewrite a little bit of the code of the Textile PR you sended. Thank you a lot
@hector I don’t know if I just found a bug or not but wanted you to take a quick look to see if I really should open an issue on Git.
I used a custom connector as I said before, and everything seemed to be working until I tried to bootstrap the peer to another one. It would bootstrap and after 5 seconds It would throw a panic error:
And instead of using the Peers method from the Cluster struct I used the Peers function from the Rest API as a work around and works fine.
Do you think this might be a problem from the lib worth of opening an issue?
Let’s see. In IPFS cluster, IPFS is a separate program with its own libp2p host and cluster has its own libp2p host as well.
In the Textile approach, the libp2p host is shared.
The connector has a SwarmPeers function which should return IPFS peers. This is used by cluster to auto-connect IPFS daemons from every peer 5 seconds or so after boot (where you get the error) (I think), via ConnectSwarms.
In the Textile version, cluster peers == ipfs peers because the libp2p host is shared after all, so they pass a function so that they can get the cluster peers from inside the SwarmPeers function.
You replaced this with Peers from restapi and somehow this ends up calling c.consensus.Peers() and somehow used the peers function from the rest api (peerListHandler?).
The panic shows that something is nil (c.consensus?). I am not sure how that can happen though at that place exactly. What consensus are you using?
Thing is, you are bootstrapping the consensus layer and probably, before being finished with it, you are also requesting Peers() from that same layer (via c.Peers()) so it might be a chicken-egg problem. You may try to make ConnectSwarms() a no-op and work your way from there. It’s not clear to me what exactly is nil that causes the panic though, given the trace.
