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