Preventing dup backend names with dynamic backends in VMODs

[Poul-Henning Kamp]

Good catch Geoff.

Yes, uniqueness of backend names affect only CLI and VSM.

The former only if people get confused, the latter always because
the VSM counter segment is named based on the backend name, so
the two will clash.

We've never had a really good model for backend names and we're
probably about to make it even worse with dynamic backends.

To _truly_ identify a backend, you need to know:

	VCL name (Soon: .. or global)
	VMOD name
	VMOD object name
	VMOD object instance (= vcl name of instantiated object)
	Backend name
	IPv4
	IPv6

Needless to say, that doesn't work.

(Previously we used {backend name, ipv4, ipv6} that didn't work
either, and since then we grew vmods and dynamic backends.)

My current thinking is that we'll name the backend whatever the
user/vcl/vmod writer likes (ie:  Backend name), and deal with the
fall-out.

That really only leaves one question:  What do we do when some code
tries to add a backend with a name which already exists.

One option is to fail the backend creation, but since it is only
CLI/VSM that can get confused, that seems too draconian to me.

So I'm tempted to simply add a ".%d" suffix for ever increasing
%d's until the name becomes unique.

Would that work for people ?

Poul-Henning

PS: I also noted that backend names can become quite unwieldy, so
it might be a good idea to give all backends a serial number
which appears in CLI output, and can be used in CLI commands
to refer to a particular backend.

-- 
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.