vtest and varnish-cache repo relationship

Dridi Boukelmoune dridi at varni.sh
Mon May 12 09:55:51 UTC 2025


Hello Willy,

> We do indeed have out own H3/QUIC implementation, but it's independent
> on vtest. For us, vtest is a totally standalone tool. We simply update
> it from time to time. Also it totally makes sense to me to use ngtcp2
> and nghttp3 for vtest, because these libs are widely used and generally
> considered as a reference implementation, something that vtest would
> definitely benefit from.

How bad would it be on the haproxy side to maintain haproxy support in
a shared library?

    varnishtest -m libvtc_haproxy.so ...

The idea being that your library gets to register its specific
commands callbacks (haproxy, maybe others?) and rely otherwise on
built-in commands like client and server.

> In any case I don't think that varnish using vtest as an external
> dependency would be a good idea. It would first create an extra
> maintenance burden for varnish, and second, create difficulties when
> other projects start to adopt vtest because they will not realize that
> the changes they propose can have an impact on varnish itself.

I agree and I worry about how much this would compound when LTS
branches are involved, in particular when we need to produce a fix
fast and we can't just reuse the test case without first dealing with
vtest back-ports one way or another.

Dridi


More information about the varnish-dev mailing list