ping endpoint can now wait for leader

[otoolep]

With this change the ping endpoint now accepts an optional parameter wait_for_leader, which should be supplied with a timeout. If set then the endpoint will not return until the system has a Raft leader, or the timeout passes. If the timeout passes 503 is returned.

If the timeout is 0, then the endpoint waits forever.

https://github.com/influxdb/influxdb.com/issues/438

[otoolep]

@corylanou @beckettsean

[corylanou]

nit: this should be /ping?wait-for-leader=1s. Underscores technically need to be encoded in a parameter name.

[otoolep]

So you're suggesting we change the API? I didn't know this. Can you provide a reference?

[corylanou]

ah, it appears I'm wrong. An underscore doesn't need to be encoded, but I've seen code that encodes urls encode them to %5f in the past, so I assumed (incorrectly) it was part of the spec. Personally, I don't like underscores in urls as they are hard to read, but that's a preference thing. As long as we are consistent in our API that is probably what matters.

[otoolep]

Well, at the risk of bike-shedding, I think we should differentiate between the path i.e. ping and a query param. I also prefer hyphens in the paths, but query params seem different to me. For example, Twitter uses underscores in its query params.

[corylanou]

yup, all good by me. If there was a spec it would be different, but because there is not, consistency is the only thing that really matters.

[corylanou]

Very nice! one minor nit. +1.

[otoolep]

Since @corylanou seems to have left it at my discretion, I am going with underscores for our first multi-word query param. We can still change before 0.9.5 releases if necessary.

[gunnaraasen]

I'm a little late to this, but just want to pitch some alternatives to wait_for_leader.

• The ping endpoint could check for a leader and return http.StatusServiceUnavailable if none exists and http.StatusNoContent if a leader exists.
• The ping endpoint could include another header like X-Influxdb-Status or X-Influxdb-Cluster with a value like available or unavailable.

Both of these would then allow a client to poll for the status of a node instead sending a request and waiting potentially several seconds for a response. Most clients would need to have some kind of polling in place anyway since the HTTP timeout would be tripped for any serious cluster problems.

[otoolep]

Clients can still poll. Simply set the timeout to, say, 1ms and keep requesting until the client gets 204.