From guillaume.quintard at gmail.com Sat Apr 23 13:57:19 2022 From: guillaume.quintard at gmail.com (Guillaume Quintard) Date: Sat, 23 Apr 2022 06:57:19 -0700 Subject: Public alternative to VFP_Push Message-ID: Hi! With 6.6, VFP_Push was made private, but it looks like there's no alternative for it. I've seen VCL_StackVFP, but it's equally private. For context, I'm currently using VFP_Push in https://github.com/gquintard/vmod_reqwest/blob/4aecc793643d5eb395c43cbbad463c7b0deef6ab/src/lib.rs#L658 , pretty much exactly like Varnish does it internally: - have a backend with a gethdrs method - get called by VDI_GetHdr - once the headers are in, use VFP_Push to inject a processor at the start of the pipeline It works very well, but if there's a way to respect the API boundaries, I'd be happy to abide. Cheers, -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Apr 25 09:12:56 2022 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 25 Apr 2022 09:12:56 +0000 Subject: Public alternative to VFP_Push In-Reply-To: References: Message-ID: <202204250912.23P9CuZc018003@critter.freebsd.dk> -------- Guillaume Quintard writes: > With 6.6, VFP_Push was made private, but it looks like there's no > alternative for it. I've seen VCL_StackVFP, but it's equally private. The alternative is to edit the filter_list variable. The problem with VFP_Push() is that you cannot control the order in any usable way, whereas editing the filter_list gives you full control. At least that's the theory why we did it :-) If it doesn't work in practice we will have to do something about it... -- 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. From slink at schokola.de Mon Apr 25 10:02:58 2022 From: slink at schokola.de (Nils Goroll) Date: Mon, 25 Apr 2022 12:02:58 +0200 Subject: Public alternative to VFP_Push In-Reply-To: <202204250912.23P9CuZc018003@critter.freebsd.dk> References: <202204250912.23P9CuZc018003@critter.freebsd.dk> Message-ID: <39b5097a-f6d7-0981-f543-2d63171a3248@schokola.de> On 25.04.22 11:12, Poul-Henning Kamp wrote: > If it doesn't work in practice we will have to do something about it... > FWIW, we also need to push filters in pesi[1] very similar to how core ESI code does. As pesi is so tightly coupled to core code, and, consequently is a "VARNISHSRC" vmod, that I do not care about API boundaries, but the use case might be more general: A filter might determine that it needs/wants to push more filters after processing of the filter list is finished, if only for modularity. How relevant this use case is for vmods which could otherwise limit themselves to just VRT I do not know. Nils [1] https://code.uplex.de/uplex-varnish/libvdp-pesi From guillaume.quintard at gmail.com Mon Apr 25 14:54:40 2022 From: guillaume.quintard at gmail.com (Guillaume Quintard) Date: Mon, 25 Apr 2022 07:54:40 -0700 Subject: Public alternative to VFP_Push In-Reply-To: <39b5097a-f6d7-0981-f543-2d63171a3248@schokola.de> References: <202204250912.23P9CuZc018003@critter.freebsd.dk> <39b5097a-f6d7-0981-f543-2d63171a3248@schokola.de> Message-ID: Thank you for both of your answers! On 25.04.22 11:12, Poul-Henning Kamp wrote: > The problem with VFP_Push() is that you cannot control the order in > any usable way, whereas editing the filter_list gives you full control. The theoretical issue I have with this is that to use filter_list, I need to register the filter, which opens it to be used by VCL writers, even though the vmod should be the only one fiddling with it (notably because it must be the first in line, and only after some internal setup happened). On Mon, Apr 25, 2022 at 3:03 AM Nils Goroll wrote: > As pesi is so tightly coupled to core code, and, consequently is a "VARNISHSRC" > vmod, that I do not care about API boundaries, That's convenient :-) I'm probably going to do the same. The slight annoyance in my case is that I have to decide whether to expose VFP_Push (and possibly others) in the rust bindings (breaking the API barrier way upstream), or if I just let vmods declare the bindings themselves downstream. At the moment I don't care because I own the bindings and all the rust vmods I know of, but it may change at some point (and we can wait until them until exploring this again). -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume.quintard at gmail.com Thu Apr 28 20:38:00 2022 From: guillaume.quintard at gmail.com (Guillaume Quintard) Date: Thu, 28 Apr 2022 13:38:00 -0700 Subject: vmods and docker containers got easier Message-ID: Hi everyone, Here's a triplet of announcements that should make life easier for a bunch of vmod users. # install-vmod Earlier this month I pushed https://github.com/varnish/toolbox/tree/master/install-vmod which, I must admit, takes inspiration from xcir's vmod-packager ( https://github.com/xcir/vmod-packager), but with a way less ambitious scope. Essentially, you can just point install-vmod at a tarball (local or remote), with an optional checksum and it will download, build, test and install the vmod for you: install-vmod https://github.com/varnish/varnish-modules/releases/download/0.20.0/varnish-modules-0.20.0.tar.gz e63d6da8f63a5ce56bc7a5a1dd1a908e4ab0f6a36b5bdc5709dca2aa9c0b474bd8a06491ed3dee23636d335241ced4c7ef017b57413b05792ad382f6306a0b36 It's only a few lines of shell and doesn't handle dependencies installation, but it's pretty convenient for the next point. # install-vmod in official docker images install-vmod is included in all official images, making it very easy to supplement the images with your own vmod combinations. Here's a and example taken from the official docs (https://hub.docker.com/_/varnish): FROM varnish:7.1-alpine # install build dependencies USER root RUN set -e; \ apk add --no-cache $VMOD_DEPS; \ \ # install one, possibly multiple vmods install-vmod https://github.com/varnish/varnish-modules/releases/download/0.20.0/varnish-modules-0.20.0.tar.gz; \ \ # clean up apk del --no-network $VMOD_DEPS USER varnish Note the VMOD_DEPS that allows you to quickly add and remove the general building dependencies. # official docker images now include varnish-modules and vmod_dynamic Now that images have an easy way to install vmods, it seemed like a waste to not install a couple of those, namely: - varnish-modules (https://github.com/varnish/varnish-modules) because it's full of tools that are useful in most setups (headers, var, str, etc.) - vmod_dynamic (https://github.com/nigoroll/libvmod-dynamic) since containers usually live in dynamic environments with backend with a DNS record but no fixed IP And those two have the big benefit of not requiring any extra dependencies compared to Varnish, meaning the image size only slightly increased. And that's it for now! As usual, feedback is welcome, especially since the features are so new. Until next time! -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: