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