Skip to content

VDD22Q2

Jump to bottom Edit New page
Dridi Boukelmoune edited this page Feb 10, 2023 · 1 revision

NOTES

martin on varnishlog scalability

  • logging is a killer feature which users' business cases depends upon

  • Some users would rather see clients wait than losing a log record.

  • log clients are single threaded

  • for multiple queries, basic structure building done per log client

  • ideas

    • binary log nice to have, not a solution

    • solve desync issue by giving the option to report lost entries

      • or throttling / blocking varnishd

    • merge logging into varnishd

    • drop session logging, copy session attributes into request scope

    • potential to optimize logging away (kills varnishlog -d, could keep internal buffers longer instead)

    • varnishlogd muti-query multi-thread (read shm and fan out to pipes/udses)

    • structured shared memory

    • use utility threads inside varnishd to write logs to fs, which is then read by the clients.

    • compiled queries

    • pluggable, custom log implementations in varnishd, renovate interface first (phk)

  • side topics

    • custom tags for vmods

    • log all counter diffs

phk jumps agenda and talks about how he spent the covid period

Rational R1000 machine at datamuseum.dk

Varnish Association / Charity / Forening / Verein / Foundation

  • martin talks about VS efforts in this direction

  • VS owners have welcomed the idea

  • slide set from law firm LUCENTUM

    • disputed: Transfer copyright to foundation?

    • maybe not even relevant?

    • Lots of commitees

    • trademark: VS AB owns, licenses it to Verein

    • cost: VS willing to take on running costs

  • Should the entity spread money for development "centralized VML"

  • nils presents ideas for bylaws

  • most important questions

    • do the bylaws get the verein involved in money etc?

    • "grassroots" or "corporate" style?

TLS

  • arguments: - ToS / QoS by content - Adaptive Congestion Control by content - kernel TLS for mallanox hw offload

  • use cases

    • dynamic loading of certificates based on SNI from VCL

    • not just by name, want to prefer specific cert

    • session key sharing

    • vcl_${proto} {}

    • client certificates for backend connections

  • should use something along the lines of CF keyless

    • no private keys in varnishd worker process

    • cert server should be pluggable, should have some kind of CLI

    • could significantly complicate H3

  • martin: have done poc for plugging "keyless" as openssl encryption engine

    • seems hard to do it ssl lib implemention independent - try to not make it hard to switch impl

    • VS: linking against stock openssl

  • stack transports?

  • do the work

    • UPLEX has sponsor

    • VS might upstream as open source

    • limit the scope to OpenSSL >= 1.1 ?

    • strawman the vcertd (dridi?)

  • varnishtest

    • dridi has done 2 rounds of polishing of https in varnishtest

    • dridi has plans for a 3 round before porting to trunk

    • to submodule SOONER (revive slinks PR?)

      • when varnish is branched off, the vtest code can be bundled (no submodule)

      • needs patch back-ports convenience

      • refs

    https://github.com/vtest/VTest/pull/2

    https://github.com/varnishcache/varnish-cache/pull/2838

H3

  • Lars is still working on the quant project
  • should look at msquic
  • quictls openssl fork for quic
  • haproxy has own quic
  • argument against openssl is that h3/quic moves fast
  • probably needs a new survey of available implementations (asad)

extensions, pluggable stevedores and protocols (xx)

  • phk talks about changes which are going to happen

  • martin brings up loading extensions in mgmt, seems not to be a killer argument

  • built-in stevedores stay in varnishd

  • built-in stevedores will register before extensions, so default=malloc|umem will remain

  • martins batch insertion

    • HSH_Insert() EXP_Insert() BAN_Insert() batched functions

    • martin+slink

>1 level of return(vcl, prefix="example.com"")

  • current implementation is just defensive

  • parameter with absolute limit on switches, default should remain just 1 level

  • structure label names? xyz/abc -> xyz can only return (vcl(xyz/abc))

    • is the prefix argument absolute or relative

    • write the docs, implement

bundled VMODs

  • discussion about varnish-modules and var vs. objvar vs. native variables in vcl

objvar today:

vcl_init {
    new myvar = taskvar.string();
}

myvar.set("foo");
set resp.http.foo = myvar.get()

objvar with designated setter/getter methods:

myvar = "foo";
set resp.http.foo = myvar;

native scoped variable suggestion:

{vcl,client,backend}.* symbols
set client.var.foo = <string expr>;
set backend.var.foo = <string expr>;
set vcl.var.foo = <string expr>;

native scoped variable alternate suggestion:

{be{re{q,sp}}}.var.* with req=>bereq and beresp=>obj=>resp copies

another scoped variable suggestion:

[global] {[req|bereq|resp|beresp]} [type] var;

beresp variables would be persisted with the object

-> write a concrete proposal for user docs (guillaume)

xkey:

- vmod as is only works with non-persistent storage

- should look at http-wg suggestion

- important feature

suggestion for inclusion into varnish-cache

- accept: Filter accept-like headers

- bodyaccess: Client request body access

- header: Modify and change complex HTTP headers

  VS to upstream headerplus?

- str: String operations

  should turn into type methods, need arguments for type methods

  task for dridi's apprentice

- tcp: TCP connections tweaking

- vsthrottle: Request and bandwidth throttling

  should be redone with modules and better methods

side discussion: issues with vmod cookie

  • removes duplicate cookies
  • need iterator over multiple cookies -> simon please open cookie

compiled VCL sideloading

  • guillaume: still need vcl even if overriding cc_command for vmod import
  • we should put vmods into .so
  • complicated because of vmod random names

slash stevedores (fixed size mem + persistent tiered)

Homework assignment for friday, read: https://httpwg.org/http-extensions/

synth bodies and filters

  • phk wants to remove the option to reset the synth body
  • vsb is contigous region, good case for discontinous object creation
  • dridi is of the opinion that vcl resetting the beresp.body should pay the cost of resetting a vfp

via backends

https://docs.varnish-software.com/varnish-cache-plus/features/backend-ssl/

dridi syntax suggestion:

backend proxy {
    .type = connect; # registered by vext proxy
    .host = "...";
}
backend b{1..3} {
    .type = http1; # built-in, default value
    .tls = true;
    .client_cert = "/bla/c{1..3}";
    .via = proxy;
    .host = "...";
    .authority = "...";
}
backend default {
    .type = round_robin; # registered by vext directors
    .via = [b1, b2, b3];
}

multiple headers with the same name

shall implement

  • xtaskvar.foreach_header(HEADER, SUB)

  • xtaskvar.foreach_cookie(HEADER, SUB)

  • HEADER.count

  • std.sanitize_headers()

    • collect all collectable headers

  • C code fail for more duplicate headers

    • date?

Legacy headers which are SF compatible could become binary

-> how could VCL look if those became a reality?

parallel/async CLI

Implement cli-like interface to vkeyservd with async/parallel syntax Check how this could look like for varnishd

Only specific commands would become async (vcl.load and vcl.inline mostly) bans could serve as a template (vcl.load -a name ... -> 205 async started / vcl.list shows "pending"/"failed") buffer output in vsb, cli command to query (vcl.show -o vcl_name, -o for compiler output) martin suggests a "job interface" jobs.list / jobs.wait name

#16 optional vmods / conditional code?

import cookie [from PATH] [or skip];

with (import cookieplus) {
    # cookieplus.do_stuff()
} else with (import cookie) {
    # cookie.do_stuff()
} else {
    # regex time
}

The end!

  • dridi:

    • HTTPS

  • phk:

    • synth bodies and filters.

  • martin:

    • Varnish Verein
    • Varnishlog scalability

  • simon:

    • TLS
    • Problems with multiple headers with the same name (jwt, cookie validation in varnish just mention it)

  • Guillaume:

    • mainline varnish modules
    • compiled VCL sideloading

  • slink:

    • 1 level of vcl.use

    • TLS in varnish: killer arguments
      • ToS / QoS by content
      • Adaptive Congestion Control by content
      • kernel TLS for mallanox hw offload
      • H3
    • Project Governance / Varnish Forening
    • finally nail via backends (+1 by Varnish Software / Pål)
    • Plans for H3
    • extensions, pluggable stevedores and protocols
    • If anyone was interested, could present the slash stevedores:
      • based on home-grown buddy allocator, with features we need for v-c
        • fixed size
        • allocations of page & extent
        • cram factor: how/when to return smaller-than-requested
        • waiting allocations with priorities
        • optionally chose "nearest" page based on double value
        • batched alloc/free for efficiency
      • buddy: in memory
        • all of the above as a storage engine with
          • "nearest by expiry"
          • no more lru_nuke_limit
        • plus
          • configurable reserve to immediately serve requests when LRU kicks in
      • fellow: 2 tier ram + disk
        • persistent
        • always consistent on disk with log
        • async io
        • checksummed
        • RAM LRU per segment (= supports objects larger than RAM)
Add a custom footer
Add a custom sidebar
Clone this wiki locally