Preventing dup backend names with dynamic backends in VMODs

Geoff Simmons geoff at uplex.de
Mon Oct 26 16:31:02 CET 2015


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

Hello all,

I'd like to get back to some questions I asked in IRC earlier today. I
guess I didn't make the problem clear, so let me try to explain why I
think this is critical.

struct director has the fields vcl_name and name, and struct backend
has the field display_name -- when a backend is statically declared as
"backend foo", those fields are all derived from "foo". Some uses for
backend names are: display in backend.list; the strings against which
a backend.set_health expression are matched; and construction of stats
in the VBE.* namespace.

Prior to 4.1, it was impossible for a VCL to have two backends with
the same name, because the VCC compiler doesn't allow it. Now that
backends are VMOD-able, they can be created dynamically at runtime,
with any name you like. The points I want to make are: a serious
implementation of dynamic backends would have to enforce the same
restriction, no two backends with the same name per VCL; but it can't,
because there's no way for a VMOD to determine if a backend with a
certain name already exists in a VCL.

I tried it out, and varnishd in fact has no problem using backends
when there are duplicate names, since they are known internally by
pointers to struct backend, which of course are distinct regardless of
the name fields. So with something like this:

import backend_dyn;

backend be { .host="${s1_addr}"; .port="${s1_port}"; }

sub vcl_backend_fetch {
  set bereq.backend = backend_dyn.create(name="be",
                                         host="${s2_addr}",
                                         port="${s2_port}");
}

... Varnish sends requests to the backend at s2_addr:s2_port and
receives responses just fine.

The problems are:

- - The VBE.* stats don't seem to work correctly. For the above, I see
VBE.vcl1.be.bereq_hdrbytes and .beresp_hdrbytes both == 0 after the
backend has answered requests, but both >0 when the backend names are
different.

- - backend.list shows two backends with the same name, and you can't
tell them apart. If one of them goes sick while the other is healthy,
no telling which is which.

- - There's no way to use an expression in backend.set_health that would
change the health status of one but not the other.

All of which are intolerable for operations and automatizations that
depend on these things.

So, a VMOD would almost certainly want to raise an error in this
situation. But unless I'm missing something, it can't, because there's
currently no interface available to a VMOD that tells you if a VCL
already has a certain backend name.

struct vcl is private to cache_vcl.c, so a VMOD can't inspect it's
backend_list. And I don't see any function call that will do the job,
not even in cache_priv.h (presumably because this has never been an
issue before).

Am I seeing this right?

If so, I'd suggest adding something like VCL_HasBackend(vcl,name), and
would be happy to submit a patch.


Thanks,
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

iQIcBAEBCAAGBQJWLkc2AAoJEOUwvh9pJNURrrkP/2GoFo/0BekhUugLmt8XECmO
+BnyWEMoe5SfQ+enIfz8dR0pIhsNZ3bDQ8hWQ6+bYxsdBc/AcrDnXiYT1Ia47YyR
up1Q4HLNEEVuR+OjrbehuZ6Gg9kvn3UoxtS7FMfkC2z/w295MoK+eNcnGVgmTuHj
HxzN/6odynKcU2dL7lEiXjuWaIPOmW0bP9vIwo6j83BJUHOS5QM/IbY2B0vCAmnk
mNJaNerynmMne+eIRAxK5gHJb4zudIkNkiLbqQEjN2W5+iI8HNUqHqaIlNz/0/av
83JQOOzfF9nq+hgX6ZYZwUApbV2PbB/Vt/yuX0kr5EkBEBspZymVcBq/HNyiE4BT
pHcHf6te/kVVVNaqwTbOWMG1zWggE0VeXRi+rgVSA41wv7xoDthAvS495V/gsL7N
x8gJ3i/NSt7QFPC+4/UPwb8vnNu3bsUzkzvnRJ2pRIeaOEwT3wyYK1y4lqNviAav
g1+O+wrnZCKu3Yd6j5GV1Q2tgVGJa33u41lc4UWW+7LlhstjS/UPLv4/rJrtOxgf
mltzZuKNBTmUiPtzMjdTsbUSmWl7AGK4Jd2eHiq5dswJX/85UPUZbf7+/l30oiMh
rkwM+h9yQYdNtV6FUDPK2D70bp0ndW1y5h/biKF+4+sr4dDl1o4JG+sY5HA7y9V6
2UPeAXdy0vcSLoSSANwm
=8uwn
-----END PGP SIGNATURE-----



More information about the varnish-dev mailing list