VCL storage discussion summary

[Federico Schwindt]

[ And now replying to all.. ]

Hi,

If setting or using a storage cannot fail I'd say kill _hint (eventually)
and just use storage.

If there is a chance of failing, I'd keep the _hint. I'd avoid having both.
Having backend_hint and backend is confusing enough already.

Regardless of the outcome, I think we should be more explicit on how tell
tell Varnish any storage (or the next storage for the matter) is OK.
Right now this happens under the hood and I've seen people setting the
wrong storage by mistake (typos), not realising it and asking why Transient
or some other storage is full.

Best.

On Mon, Oct 10, 2016 at 1:30 PM, Dridi Boukelmoune <dridi at varni.sh> wrote:

> Hello,
>
> Following discussions on storage/stevedore literals vs hints in VCL
> I've tried to sum up the current situation and suggest a direction to
> take.
>
> Currently we have:
>
> 1) a STEVEDORE type for VCL (storage namespace)
> 2) all storages resolved at boot time (typesafe)
> 3) beresp.storage_hint takes a STRING
> 4) no/wrong hint means round-robin among storages
>
> Today during the bugwash, following two pull requests introducing a
> storage hint for the request body (instead of systematically using
> Transient) we discussed the possibility of removing the hint part. The
> reason being 1) in the list above.
>
> After some testing on master, it doesn't seem to be enforced:
>
>     sub vcl_backend_response {
>         set beresp.storage_hint = "some random junk";
>         set beresp.storage_hint = beresp.http.x-storage;
>     }
>
> However, implicit stevedore conversion to string exists:
>
>     sub vcl_backend_response {
>         set beresp.storage_hint = storage.Transient;
>     }
>
> Suggestions:
>
> A) Keep the _hint to allow backend- or vmod-driven _loose_ storage
>    selection.
>
> B) Maybe introduce besresp.storage to avoid conversions to and from
>    STRING, but allow NULL to behave the same as 4) for the _hint.
>
> C) Be consistent when storage selection is introduced for the request body.
>
> Cheers,
> Dridi
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20161010/9feb02b0/attachment.html>