V4 VCL ideas

[Nils Goroll]

On 01/ 9/13 11:17 AM, Poul-Henning Kamp wrote:

> One possible consistent view is that _everything_ which might smell
> the least of policy, should be in VCL.  The obvious downside is
> that VCL becomes quite complicated.

I strongly believe that this is the right way to go, otherwise we won't get rid 
of magic knobs and the spirit of VCL as I perceive it is really to give control 
over all relevant aspects of Varnish in a manner as concise as possible and with 
high performance.

My impression is that VCL already is too complicated for some (just consider 
regular expressions...), so to make novices' lives easier, having a config 
generator or good templates/examples would be the way to go, IMHO.

> As far as I can tell, the major argument for the first approach
> is trust management.

I'd call it control or conciseness, but otherwise agree.

> My current mock-up default.vcl presently looks like this, input,
> ideads and comments are most welcome.
see below.

> ... and no, I still don't know what to do about vcl_error{}...

I don't feel up-to-date on this, could you summarize the situation (again?) or 
point to the most up to date information on this? The latest I have is Tollefs 
Email as of 2012-01-12 and some traces from VUG6 in my bad memory.

Other than that, I have proposed in 
https://www.varnish-cache.org/trac/wiki/Future_VCL to allow for vcl_error to not 
close the conn, which would be obsoleted if vcl_error was never called but for 
real (= varnish C-triggerd) errors.

I am also referring to the wiki page for some of the following comments:

* how would the always_miss and ignore_busy replacements look like?
* how would purge code look like?
* I think it would help to draw again the clear line between client
   and backend-side. which vcl callbacks live in which thread?

   DIUC that the line is above sub bereq ?


> sub vcl_req {

what aboot req.body and return(purge)?

> sub vcl_lookup {
> 	/*
> 	 * V4: Formerly part of vcl_hit{}, vcl_miss{} and vcl_pass{}
> 	 */
> 	if (is_pass(obj)) {

So the hit-for-pass object would be called "pass object"? When I explain the 
current hit-for-pass logic, I most often use terms like "negative caching entry" 
or "no-caching marker object". So "pass (marker) object" seems to fill well. 
More concise than "hit for pass object" anyway.


Yes, the C-code branch to hit miss and pass needs to go into lookup, definitely.

sub vcl_bereq is nice because this is just what it does.

Would I see a potential obj here (if lookup has found one)?


I feel I should really revisit this again any try to port real VCL code to this 
concept.



Nils