Preventing dup backend names with dynamic backends in VMODs

Geoff Simmons geoff at uplex.de
Tue Oct 27 16:01:46 CET 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/27/2015 01:25 PM, Poul-Henning Kamp wrote:
> 
> 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.

Something else I thought of since yesterday -- the backend names used
in VSL for entries like Backend, BackendOpen, BackendClose and so forth.

If you're using the log to diagnose a problem, doesn't help much to
have to wonder which backend it's talking about.

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

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.

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

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? The order would be probably result from
which backend was created first, which may be difficult or impossible
to determine after the fact.

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

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


Best,
Geoff
- -- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWL5HaAAoJEOUwvh9pJNUR1OsQALGdQ5Dn/kDeBZkGymKX31z6
4/Z60CHK1lPMPsHJKumxLGp7D2deN00XmygecYshUBjjM26rnSg1f1JhFlwIMd9t
Nb678+Zi3HXoOPJ+5a1KLjMSHfpqb95xZ9S0GR7B8eAHj4fZqKJWTPk5L0CRdeI3
ISxls4/OAmrHqccH/7RILbcwX/vQo/Za7HnPkgiABq9sts18HoLZik4Wrys7jjrR
XtnKKI0TXchzxvOH+uzpSE+zVZWfGTWalK8RtyQw/+8nV7gWvtlkSmlYDJ6IMrGR
buwf0GJPHGD8OSk2MHyBg3Z3JO3EuqiPK/sGGDPQZcCcjw9bSSwQlD0z+r9CjVcN
FzjeH/3iRhFIYMsDoplxyPj1h9FcjyjPGTlJutnvlDsny1Mes8I0Rm2B8ilJL5GT
wDHgduDsjh/IEi3sIes5Baj5rKPxTO1aOHg6iALIuZiExmcZ6f5XD54e1I2MYszW
ypGWDDZcnwuvBVzplwQo/swUnKBu+I9gTVKkUqq5bQfZMUrCZ/wE/7SfqXJqBZfW
JI6k28mxL8WZyO0HH5iWhfDr3QxYrumBYZPIAHEzHEkXSo5JfH0e4sMF31mfVJ21
2WzcdGZfeAilAzGJHALYGX9/HK8Hf9Bimw808V3vrdyZNBbpE+XyX8L52Qlur4pL
sGt66SERJ3V0J9ULMZbO
=6WOa
-----END PGP SIGNATURE-----



More information about the varnish-dev mailing list