Dynamic backends

[Poul-Henning Kamp]

In message <CAOXZevAC5G-kHA+gAzccG=B-jBAH3oaUTHE6HZeNqMU1rCU8-g at mail.gmail.com>
, Per Buer writes:

>We've gotten quite a bit of feedback on my blogpost outlining dynamic
>backends.

I don't think it is a good solution for a large number of reasons,
but I will spare you the list (at least for now) because I suspect
you will find my idea better:

You are right that changing VCL is a hazzle, and mixing backends
with VCL was probably a bad-ish idea, but it was also very convenient.

I think the right solution is to bite the bullet and make backends
first class objects which can either be instantiated statically in
VCL, (like today) dynamically from the CLI or by VMODs on the fly.

This allows us to move all directors to VMODS:

	import round_robin_director;

	sub vcl_init {
		backend.foobar = round_robin_director.new(
			// Not happy with passing params this way
			// a more useful syntax may be a good idea.
			// Possibly a type-tagged argv which the vmod
			// can complain about at compile time ?
			"host[1] = "192.168.60.1",
			"weight[1] = "12",
			"host[2] = "192.168.60.2",
			"weight[2] = "12",
			"host[3] = "192.168.60.3",
			"weight[3] = "24"
		);
	}

	sub vcl_recv {
		set req.backend = backend.foobar;
	}

The only real question that leaves behind, is what happens when you:

	sub vcl_recv {
		set req.backend = backend.foobar;
	}

And there is no backend named foobar ?

Today we can detect this at VCL compile time, but with dynamic backends
it becomes a runtime error, and we should probably just fail the
request with 50x.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.