Re: VCL storage discussion summary
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 gmail.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
Re: VCL storage discussion summary
In message , 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
Re: VCL storage discussion summary
Why? Is there anyone depending on this feature? When do you want to use it? Wouldn't be easier to visualise and/or explain what is going where if it's done explicitly? Also, if we allow this shouldn't be a way to disable it? My problem with this is two fold: 1, it's not documented AFAICT; and 2. people specifying the wrong storage by mistake ends up using another storage and causing evictions (seen this in a customer). Since the definition and usage is done separately, it is not that difficult to get it wrong, specially when you change one but forget to update the other. This also means that we cannot say that default means the first non-Transient storage for cache insertions. On Mon, Oct 10, 2016 at 8:23 PM, Poul-Henning Kamp wrote: > > In message g5px0xcd6ukqn+a...@mail.gmail.com> > , Federico Schwindt writes: > > >- No more RR on storages by default. If this is wanted, it should be set > >explicitly somehow (VMOD?) > > I agree with the rest, but this on I think would be unwise, we should > retain the RR behaviour. > > -- > 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
In message , Federico Schwindt writes: >- No more RR on storages by default. If this is wanted, it should be set >explicitly somehow (VMOD?) I agree with the rest, but this on I think would be unwise, we should retain the RR behaviour. -- 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
What about something like this: - NULL or "no setting" means default storage (this is the same as no backend). - default means the first non-Transient storage for cache insertions, Transient for anything else (pass and request bodies). - No more RR on storages by default. If this is wanted, it should be set explicitly somehow (VMOD?) If we failed to allocate using the selected storage we fallback to Transient, always. If Transient fails because it's capped and we couldn't make space, we fail hard. Comments? On Mon, Oct 10, 2016 at 6:42 PM, Poul-Henning Kamp wrote: > > In message rtqa686ak...@mail.gmail.com> > , Federico Schwindt writes: > > >This might be obvious but are we considering NULL a "no setting" as well > or > >only when a VMOD returns NULL? > > > >If it's the latter I agree. The former would be a breaking change. > > Well, that's why I'm asking: > > If vmod returns NULL does it mean > > A) Failure to select stevedore > > B) Use default stevedore selection > > ? > > -- > 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
In message , Federico Schwindt writes: >This might be obvious but are we considering NULL a "no setting" as well or >only when a VMOD returns NULL? > >If it's the latter I agree. The former would be a breaking change. Well, that's why I'm asking: If vmod returns NULL does it mean A) Failure to select stevedore B) Use default stevedore selection ? -- 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
This might be obvious but are we considering NULL a "no setting" as well or only when a VMOD returns NULL? If it's the latter I agree. The former would be a breaking change. On Mon, Oct 10, 2016 at 6:33 PM, Poul-Henning Kamp wrote: > > In message gg88cel9uv-k7...@mail.gmail.com> > , Federico Schwindt writes: > > >Doesn't that depend on whether is a cache insertion or pass? > > > >Are we considering changing that? > > If we have NULL for stevedore and it is an insert, I would consider > making it pass+Transient, to limit the amount of non-placed storage > we need. > > -- > 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
In message , Federico Schwindt writes: >Doesn't that depend on whether is a cache insertion or pass? > >Are we considering changing that? If we have NULL for stevedore and it is an insert, I would consider making it pass+Transient, to limit the amount of non-placed storage we need. -- 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
Doesn't that depend on whether is a cache insertion or pass? Are we considering changing that? On Mon, Oct 10, 2016 at 6:08 PM, Poul-Henning Kamp wrote: > > In message cy_rr2xju87ui...@mail.gmail.com> > , Federico Schwindt writes: > > >Assuming this will depend on whether this is the client or the backend > side > >(request vs response), yes, > > > >for the request body Transient being the default makes sense (current > >behaviour). > > You left out what will make sense on backend side ? > > I don't see an alternative to Transient, and I might even advocate pass... > > -- > 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
In message , Federico Schwindt writes: >Assuming this will depend on whether this is the client or the backend side >(request vs response), yes, > >for the request body Transient being the default makes sense (current >behaviour). You left out what will make sense on backend side ? I don't see an alternative to Transient, and I might even advocate pass... -- 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
Assuming this will depend on whether this is the client or the backend side (request vs response), yes, for the request body Transient being the default makes sense (current behaviour). On Mon, Oct 10, 2016 at 5:55 PM, Poul-Henning Kamp wrote: > > In message ctatgu2qwftqv...@mail.gmail.com> > , Federico Schwindt writes: > > >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. > > I agree, and I'd like to kill backend_hint as well. > > That said, in both cases we need to deal with "no setting" and "vmod > returning NULL". > > For backend, it's the default backend. > > Is it Transient for storage ? > > If so, I think we have a decision... > > > -- > 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
In message , Federico Schwindt writes: >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. I agree, and I'd like to kill backend_hint as well. That said, in both cases we need to deal with "no setting" and "vmod returning NULL". For backend, it's the default backend. Is it Transient for storage ? If so, I think we have a decision... -- 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
[ 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 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@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
VCL storage discussion summary
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@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
VDD16Q4 polls
Varnish C hackers (core/vmod authors) who are interested in attending a dev meeting, please fill in these doodles so we get an idea of possible options: http://doodle.com/poll/78evzv5m3c9c8rhd#table http://doodle.com/poll/5f34i577x9t7ypc4#table ___ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
