sub probe_resp - VIP RFC

Nils Goroll slink at
Tue Apr 11 15:47:13 CEST 2017

Hi, :
	"The VIP procedure starts with a discussions on varnish-dev"

I had skipped this bit for previous suggestions, but this time I want to get it
right. I'd like to propose the following:

# Synopsis

Add support for calling vcl subs on the response of backend probes.

# Why?

Add a way to manipulate backends not just on the basis of a binary health check
result, but optionally also on the basis of other information returned by the
backend with the probe response.

One example would be to dynamically change the weight of backends based on a
load metric returned with the probe response, which will also require
vmod_directors to support changing the weight dynamically.

# How?

* Add VCC support to register VCL subs with probes

* Add a default vcl_probe_resp sub to the builtin.vcl which implements the
  current behavior. Probes without an explicit response sub definition will
  use vcl_probe_resp

* in probe_resp context, make the following objects available

  - analogous to beresp

	- prresp.backend
	- prresp.http.*
	- prresp.proto
	- prresp.status
	- prresp.reason

	- later?
		- prresp.body

    By design, all access should be read-only, but we might want to
    have all but .backend writable for practical reasons (writes
    having no effect other than being visible in the sub probe_resp)

  - probe.* attributes of the probe (read-only)

	- probe.expected_response
	- probe.timeout
	- probe.interval
	- probe.initial
	- probe.window
	- probe.threshold

* a probe_resp sub may return with the following


* The default vcl_probe_resp:

	sub vcl_probe_resp {
		if (prresp.proto ~ "^HTTP/\d+\.\d+$" &&
		    prresp.status == probe.expected_response) {
			return (healthy);

		return (sick);

* Toy example for the use case mentioned above (needs more changes)

	sub probe_weight {
		if (prresp.http.X-Load ~ "^\d+\.\d+$") {
					 1 / std.real(req.http.X-Load, 1.0));

More information about the varnish-dev mailing list