Feature Request: Return 200 OK for HTTP GET to root RPC endpoint

[dan-turner]

At the moment when I curl http://localhost:8545 it 302's to the wallet UI at http://localhost:8180.

I'm trying to expose parity nodes running in Google Container Engine (GKE) that are sitting behind a Google Load Balancer. Google's load balancer will not forward traffic unless the underlying service is healthy and the only option for a Google LB health check is a HTTP GET. It would be super useful if parity could just respond 200 OK instead of the 302.

[kirushik]

Will http://localhost:8545/api/health be good enough for you? Because it's already there (with a twist of returning 412 of your node is not yet synched; not sure how you want GKE to treat such cases).

I'll reopen this issue if the current exposed API is not enough for your task; getting Parity working smoothly in k8s environments is important for us.

[tomusdrw]

Also consider running with --no-ui

[dan-turner]

My apologies but this is going to be a somewhat long-winded and complicated explanation, bear with me :)

Parity allows us to define a list of reserved nodes. To do this we need to specify a static nodes file when starting parity. Unfortunately Parity does not allow us to use hostnames in enodes, IP addresses must be used (I've never understood why this is? isn't the public key part of the enode sufficient protection against impersonation?). Therefore our only option is to resolve the IP's of the peers and generate a static nodes file before starting Parity. But now we have a chicken and egg problem. We can't generate our peer list until they're ready and they can't be ready until a peer list is generated and parity is started. We've managed to hack it by specifying a no-op bash based readiness probe. This gets our statefulset up and ready, but when we try to bind it to an ingress, the ingress itself never becomes ready because the ingress itself executes a HTTP healthcheck to / unless your readinessProbe defines an alternate httpGet healthcheck (which we can't - we need the no-op bash readiness probe to peer).

Suggestions

• Allow hostnames in enodes. All of these problems would melt away, I could bind the readinessProbe to /api/health, each node would start, DNS would then resolve, peers could be resolved by their hostname in the static nodes file.
• Consider returning health info from the root endpoint as well as (or instead of) /api/health. Particularly with the --no-ui flag set, the 404 offers very little value IMO.

[5chdn]

But now we have a chicken and egg problem. We can't generate our peer list until they're ready and they can't be ready until a peer list is generated and parity is started.

You can break up this circle by adding reserved peers via parity_addReservedPeer call.

https://paritytech.github.io/wiki/JSONRPC-parity_set-module#parity_addreservedpeer

[kirushik]

@dan-turner I really like to hear more about your usecase and see what we can do about it. Also I understand that not everyone comfortable discussing their infrastructure details in publicly-visible issue tracker (I wouldn't be, for example =).

Do you mind sending me a mail to [email protected] (or, maybe even better, a message to my Matrix account @Kirill:matrix.parity.io), and we'll see how to better set things up for your case, and what changes do we need to implement in Parity for that?

[dan-turner]

Hi @kirushik, did you get my messages that I send to your Matrix account?

[kirushik]

@dan-turner Unfortunately no, so really thanks for bringing this up.
I have no idea why matrix might be not working: federation issues? antispam measures? case-sensitivity for nicknames?.

Let's just use emails for now, and then see?

[levino]

BTW the health endpoint is not documented: https://wiki.parity.io/index.html?q=%2Fapi%2Fhealth

[webjunkie01]

I also need this. I want to expose a parity node to a Linode Balancer but the balancer can't perform POST request with a header as application/json, only simple GET requests. So every time I perform a get request to http://ip-address:port/api/status or http://ip-address:port/ the parity node always replies with "Used HTTP Method is not allowed. POST or OPTIONS is required". Thus the balancer marks the node as not healthy.

This just forces me to stick with geth nodes at the moment.

[levino]

I do not think that the method is the problem. See https://github.com/paritytech/wiki/issues/119#issuecomment-413868081:

Closing as the health api has been removed.

[webjunkie01]

Ok I see, I actually don't need the health api. So I guess my main question is how can I expose the parity node to my load balancer with a simple GET request that returns a 200 OK status so my load balancer marks it as ready to go or healthy in this case.

[dan-turner]

We had to add nginx in front of it... Return 200 OK for / or otherwise forward the request to Parity.

[webjunkie01]

Hey @dan-turner nice solution. I'll give it a try, thanks!.

[levino]

@dan-turner So you are giving back a valid health check even if parity is down? That is not a nice solution. It should be possible to switch off the health check in the LB completely, right?

[webjunkie01]

@levino In my case the load balancer is dumb, it does not care or doesn't know how to parse the response content data. To check if the node is synced or not (healthy) I use a combination of the geth console and a bash script.

[tomusdrw]

@webjunkie01 @dan-turner @levino you can do GET on websockets port (8546) to figure out if Parity Ethereum is running. I'm also working on a proper solution that returns 200 only if the node is synced and connected to peers.