VDD summary

Poul-Henning Kamp phk at phk.freebsd.dk
Tue May 15 06:24:38 UTC 2018


Thanks to everybody at the VDD in Oslo yesterday, I think we got a
lot done and we certainly ended up with one of the most actionable
summaries we have ever had.

See you in Hamburg next time:

	27.9. optional VDD if we want
	28.9. VDD
	29.9. optional fun day including TMBG concert *) or techno party depending on taste

	*) need to book yourself if you want to go


H2::Send_Frame move to ->error
#1799

Pluggable ops for TCP-Pools and TCP operations 
=> Proper way to do this is to generalize and come up with multi-protocol backend support
=> Unknown/large scope: unlikely for a Sept release

#2573 @^#@&^#@-Headers (vmod_header[s])
=> New vmod_header. @Steven writes/proposes .vcc file
=> New parameter: header-charset ?  return 400 if not acceptable.  Default=what VCL can handle.

SELinux: maintain a policy upstream
=> we ship a policy if we can test it (dridi to figure this out) (That really goes for *anything* in our tree)

CLI:JSON:
=> First step is implement -j in all commands

VFP/VDP in vmods
=> If filter-list is set, setting do_{gzip|gunzip|esi} gives Failure

libvgz compilation warnings

    inflate.c:1232:25: error: this statement may fall through [-Werror=implicit-fallthrough=]

                 state->mode = LENGTH;

                 ~~~~~~~~~~~~^~~~~~~~

    either: -Wno-error=implicit-fallthrough= if the code supports it, or just -Wno-error

    (new zlib code is still affected by this)


    Reported upstream:

    https://github.com/madler/zlib/issues/316


    => separate "varnish" CFLAGS (warnings) from the rest

    => don't pass varnish CFLAGS to foreign code

    => don't treat sanitizer flags separately? 



Features for Sept 2018 release?

    VCL variables? (see https://etherpad.wikimedia.org/p/vdd17q3 lines 103-114)

    release proc/docs etc.

    * docs:

    changes.rst / vs. sphinx/whats-new/changes-X.X.rst

    new definition: doc/changes.rst only as a hint to release managers


#1799
=> Pål wrote this: https://github.com/varnishcache/varnish-cache/compare/master...hermunn:master-cache-behavior-vmods and Martin has added some comments. Also, Nils had some comments in an email.
=> Implement func pointer zegerman_catflap() veto function from HSH_Lookup{} slink to write PR
=> Reimplement req.grace, vcl_hit{} becomes "return(deliver)". (Pål does a PR for this)

Director/Refcount/Probe
=> phk suggests BACKEND std.resolve(BACKEND) (slink says it doesn't work for shard directors, which phk thinks is shard's problem, not his.)
   -> explained and would be solved by cookie idea below
   -> a general mechanism for passing private data from the client to backend side may be interesting --> describe some use cases to phk to persuade him of the usefulness

       -> this may be where introducing variables becomes interesting, e.g. declare INT req.var.foo, which then becomes available as an INT as bereq.var.foo
XXX: why wouldn't it simply by var.foo both places ?

=> new CLI command: backend.tell <glob> args
=> ... if glob matches multiple backends, error-returns are ignored
=> ... Should "?" args be magic ?
=> "lightweight" directors for req.backend_hint, storing "cookie" on req.ws which is copied to bereq.ws and reinstated. (?)
=> What happens if backend_hint is shard with shards under it ?  How do 2nd-level shards get cookies ?
  -> slink volunteers to write PR if phk wants him to

VDP cleanup and API changes (#2673)
=> Sounds fine, consider slink's comments, reiterate, then PHK to review

VRT_CTX, priv->free(), calls outside VCL methods (VDI) (and object destructors?)
=> This one sounds sensible, but requires some homework wrt. breaking APIs and if priv's need broken more (ie: dynamic objects)

(again) native VCC type for regexen
=> VCL_REGEXP, compiler turns CONST-STRING into vre

Next VDD on Norway-Denmark boat ?
No: TMBG concert in Hamburg


-- 
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.


More information about the varnish-dev mailing list