Re: VCL storage discussion summary
In message
, Federico Schwindt writes:
>Regardless of the RR, any comments or guidelines to move this forward?
Having read the thread again, I suggest:
Before vcl_backend_response{} we point beresp->storage to the next
stevedore RR-wise. (Today we do it later, because it is a hint).
If at the end of v_b_r{} beresp->storage is non-NULL, we use that
stevedore and only that stevedore.
If at the end of v_b_r{} beresp->storage is NULL, we take it to
mean storage failure and we 50x.
That means you can still salvage inside v_b_r{}:
beresp->stevedore = vmod.forklift();
if (!beresp->stevedore) {
beresp->stevedore = Transient;
beresp->uncacheable = True;
}
For compatibility, if VCL sets beresp->storage_hint, and the string
is a stevedore name, we *also* set beresp->storage, but on failure
we leave it alone.
I belive that gives the semantics you desire in a POLA compliant fashion ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@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@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
Re: VCL storage discussion summary
Regardless of the RR, any comments or guidelines to move this forward? Should we stick to the _hint and gc in the next major release? On Mon, Oct 10, 2016 at 11:19 PM, Federico Schwindt wrote: > In my experience setups defining multiple storages are few and they use > them explicitly (in VCL). > > While I'm not necessarily advocating this change I think this will be > closer to how someone would expect it to work. > Waiting for the next major release and documenting the change might do the > trick. > > On Mon, Oct 10, 2016 at 8:43 PM, Poul-Henning Kamp > wrote: > >> >> In message > ail.com> >> , Federico Schwindt writes: >> >> >Why? Is there anyone depending on this feature? >> >> Pretty much anyone with two -s arguments are, and they probably dont know >> it. >> >> >Wouldn't be easier to visualise and/or explain what is going where if >> it's >> >done explicitly? >> >> This doesn't preclude doing it explicitly, it merely maintains existing >> configs working. >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> p...@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@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
