CLI command vmod.tell
dridi at varni.sh
Fri May 18 14:04:20 UTC 2018
On Fri, May 18, 2018 at 11:30 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <e8975e99-3370-641f-362f-5841d38b912d at uplex.de>, Geoff Simmons write
>>> vmod.tell somevcl::somevmod "bla bla bla"
> I looked a bit at this.
> There is a hurt of locking issues for VMOD writers trying to do
> anything smart, but trivial stuff like setting global options for
> the VMOD etc, shouldn't cause trouble.
> VCC wise I think this will be a "$CLI" stanza, and the function
> will get called with a VRT_CTX and a char **, and return an enum
Can we also pass a nonce to the VMOD? So that "global" actions can be
skipped once done when a VMOD like xkey is targeted with a VCL pattern
matching more than once.
> I think I prefer this naming:
> vmod.tell [VCL_PATTERN:]VMODNAME arguments [...]
> The default VCL_PATTERN will be the active VCL.
> In other words:
> vmod.tell std bugger off
> only hits the std vmod in the active vcl, whereas
> vmod.tell *:std bugger off
> will hit the std vmod in all vcls which has imported it.
> When used without a pattern:
> If the active VCL has not imported a vmod of that name
> status is CLIS_CANT.
> If that VMOD does not implement $CLI it will be CLIS_UNIMPL.
> Otherwise the VMODs $CLI determines the status.
> When used with a pattern:
> If no VCLs are matched by pattern: CLIS_CANT
> If the VMOD is not loaded in any of the matched VCLs: CLIS_CANT
> If no hit VMOD implements $CLI: CLIS_UNIMPL.
> If any hit VMOD's $CLI returns non-200: new status CLIS_KABOOM (=202)
> Otherwise CLIS_OK
> Still waffling on:
> Should names of VCLs be put into cli output as subheadings when
> pattern is used so VMODs won't have to do that, or should they
> only be added in front of VMODs which produce cli output.
> 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.
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
More information about the varnish-dev