Preventing dup backend names with dynamic backends in VMODs

[Poul-Henning Kamp]

--------
In message <562F91DA.8010104 at uplex.de>, Geoff Simmons writes:

>> 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.
>
>At the very least, VMODs should have a way to discover if a backend
>name is already in use by a VCL -- the VCL_HasBackend(vcl,name) idea.
>Then a VMOD can choose to raise an error for duplicate names.

Agreed.

>Maybe add a sentence or two to the "Writing a Director" doc about
>backend names, what they're used for, and why this could be a problem.

Also a good idea.

I'm starting to think that maybe we should have a "name-spaces"
section in the reference manual for stuff like this.

>> So I'm tempted to simply add a ".%d" suffix for ever increasing 
>> %d's until the name becomes unique.
>
>If you thought that you called your backend "be", and then see "be.1"
>and "be.2" in backend.list, VSL, VBE.* stats and so forth, is it
>really any less confusing?

Well, there are degrees of confusion, and I think people would
generally be able to grok indicies like that.

>The order would be probably result from
>which backend was created first, which may be difficult or impossible
>to determine after the fact.

Not if we make it possible to query the full list of attributes from
CLI, so that you can ask about be.3 and get told which VCL created,
which VMOD in that VCL, and which object in that VMOD etc.  Basically
the full shopping-list from my first reply.

>That would have the advantage that one set of VSC stats doesn't get
>lost altogether.

Yes.

>So I guess the choices are: be draconian, or permit a situation that
>will probably create confusion, however much we try to minimize it.

The main reason I don't like draconian is that it is not necessary.

If we're draconian, VMODS have to do a complex errorhandling, which
in 3 cases out of 10 doesn't get implemented and therefore leads to
backends not existing when they are expected to and worst case
crashes.

Varnish can run even with 98 backends all called "be" and the problem
can be corrected with a new and more sensible VCL, without ever
going out of production.

Adding the .%u suffix makes the situation workable for people who
make that mistake, and once they have sorted it out, it doesn't get
in the way for them.

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