Re: SHA256 from file descriptor

On Wed, May 22, 2024 at 10:40 AM Poul-Henning Kamp wrote: > > ---- > Dridi Boukelmoune writes: > > > > Yes, but what do we need that for ? > > > > We don't, I'm working in a VMOD that computes hashes of regular files > > among other things. Thi

Re: SHA256 from file descriptor

> Yes, but what do we need that for ? We don't, I'm working in a VMOD that computes hashes of regular files among other things. This looked like generic code not specific to that VMOD. > > Would the attached patch be welcome? > > If we have a need, that's pretty much how I would do it. If you

Re: SHA256 from file descriptor

> Slightly off topic, why have both definitions? > > #define VSHA256_LEN 32 > #define VSHA256_DIGEST_LENGTH 32 A question for upstream... https://github.com/varnishcache/varnish-cache/commit/1f631aa61dd170aa3bdd6485fbdb801c7cc36eb0

Re: SHA256 from file descriptor

> > > What's the usecase ? > > > > > > If regular file: Why not mmap and save the kernel/userland copies ? > > > > Because the code from which I extracted this function was doing a copy > > while computing the checksum on the fly, so I didn't consider mmap > > when I extracted the read part of

Re: SHA256 from file descriptor

On Tue, May 21, 2024 at 5:38 PM Poul-Henning Kamp wrote: > > Dridi Boukelmoune writes: > > > Are we interested in that kind of change (see attached diff) or do we > > strictly stick to the original source that was bundled in libvarnish? > > What's the usecase ? > &g

SHA256 from file descriptor

Hi, Are we interested in that kind of change (see attached diff) or do we strictly stick to the original source that was bundled in libvarnish? Dridi diff --git c/include/vsha256.h i/include/vsha256.h index 8f20505fce..b7c9872da7 100644 --- c/include/vsha256.h +++ i/include/vsha256.h @@ -41,6

Re: Coverity Scan: Analysis completed for varnish

On Mon, Nov 20, 2023 at 8:11 AM wrote: > > > Your request for analysis of varnish has been completed successfully. > The results are available at >

Re: Looking for tips to install varnish-modules

On Mon, Aug 21, 2023 at 8:31 PM Kari Cowan wrote: > > Installing varnish-modules > https://github.com/varnish/varnish-modules > - has generic install notes > > Version for Varnish7.3 > https://github.com/varnish/varnish-modules/releases/tag/0.22.0 > - unloaded and untarred in /home/VarnishAdmin >

Re: gcc -fanalyze fyi

On Fri, Jul 14, 2023 at 4:26 PM Nils Goroll wrote: > > FYI: > > Triggered by some promising news *) I built gcc trunk > (0d2673e995f0dd69f406a34d2e87d2a25cf3c285) and tried -fanalyze. > > I looked at the first couple of reports and believe they were all false > positives. Also it seems gcc does

Re: Varnishtest client user agents

On Wed, Jul 12, 2023 at 7:18 AM Poul-Henning Kamp wrote: > > ---- > Dridi Boukelmoune writes: > > > > I would prefer you do not overload any Well Known Headers. > > > > > > X-VTC: c1 > > > > > > maybe ? > > >

Re: Varnishtest client user agents

On Wed, Jul 12, 2023 at 6:59 AM Poul-Henning Kamp wrote: > > ---- > Dridi Boukelmoune writes: > > On Wed, Jul 12, 2023 at 5:21=E2=80=AFAM Poul-Henning Kamp > dk> wrote: > > > > > > > > > Dridi Boukelmoune writes: > > > > &g

Re: Varnishtest client user agents

On Wed, Jul 12, 2023 at 5:21 AM Poul-Henning Kamp wrote: > > ---- > Dridi Boukelmoune writes: > > > Would it be OK to have `client cNAME` send a `User-Agent: vtest > > (cNAME)` or similar to reduce some of it? > > I generally just use /c1 /c2 etc in the URL ?

Varnishtest client user agents

Greetings, When I write test cases involving multiple requests that don't need to come from the same client session I try to make one client per request. When a client reports something wrong, it's usual very convenient because I don't have to track down too many events. When I need to jump from

Re: Idea for multi-level CLI access control

On Tue, Jun 27, 2023 at 9:24 AM Poul-Henning Kamp wrote: > > ---- > Dridi Boukelmoune writes: > > On Mon, Jun 26, 2023 at 6:39=E2=80=AFPM Poul-Henning Kamp > dk> wrote: > > > > > > Regarding the specific suggestion above, I don't think we

Re: Idea for multi-level CLI access control

On Mon, Jun 26, 2023 at 6:39 PM Poul-Henning Kamp wrote: > > We talked about the overall security model during bugwash today and > while trimming the hedges I had the following idea: > > Today the fundamental authentication to open a CLI port is that > that you have access to the exact and entire

VDD23Q1 Oslo

Greetings, We are hosting our next Varnish Developer Days (VDD) in Varnish Software's office in Oslo on February 6 and 7. During these two days, Varnish core developers and VMOD authors can meet in person to discuss current challenges and future changes in the Varnish design. We have a limited

Re: Bugwash today at 15:00 EU time...

On Mon, May 23, 2022 at 9:16 AM Poul-Henning Kamp wrote: > > Can we please try to get the bugwash back on track ? > > If the monday 15:00 has become inconvenient for people we should try > to find another and better timeslot. Not sure about everyone else, but Monday is still the best option for

Re: bo access from VFP

On Fri, Jan 7, 2022 at 2:40 AM Guillaume Quintard wrote: > > As usual, thanks a bunch for all your help! > > Using the THR_* functions work: > https://github.com/gquintard/vmod_rers/blob/270a2f4272be49f8c1c904b899ec91dafcf2f873/src/lib.rs#L227 > and they allow me to merge most of the vfp/vdp

Re: bo access from VFP

On Fri, Dec 31, 2021 at 11:48 PM Guillaume Quintard wrote: > > Small follow-up on that one: it would be nice for VFP to be able to disable > streaming (bo->do_stream), so that's an extra argument to be able to access > the busyobj > > -- > Guillaume Quintard > > > On Sun, Dec 26, 2021 at 6:11

Re: Making libunwind the default

On Mon, Sep 7, 2020 at 10:28 AM Poul-Henning Kamp wrote: > > ---- > Dridi Boukelmoune writes: > > > After a brief discussion on IRC I agreed to provide comparative stack > > traces, I'll find some time to make a couple up. > > Status in FreeBSD-land: > > T

Re: Packaging: why does the RPM spec have both Provides & Obsoletes for the same packages?

Hey Geoff, On Tue, Aug 24, 2021 at 2:40 PM Geoff Simmons wrote: > > Hello, > > The spec file for RPM packages: > > https://raw.githubusercontent.com/varnishcache/pkg-varnish-cache/master/redhat/varnish.spec > > ... has this passage: > > Provides: varnish-libs%{?_isa} = %{version}-%{release} >

Re: Reintroduce a req.uncacheable flag

Hi Geoff, It's been a while, I hope you are doing well :) On Fri, May 28, 2021 at 5:22 PM Geoff Simmons wrote: > > On 5/28/21 17:50, Dridi Boukelmoune wrote: > > > > First, we already have a relationship between bereq.uncacheable and > > bereq.uncacheable: the f

Reintroduce a req.uncacheable flag

Greetings, I would like to reopen a discussion started by Guillaume via a pull request: https://github.com/varnishcache/varnish-cache/pull/3457 For reasons other than the ones he exposed I have reached the conclusion that such a flag would be both relevant and useful. Not req.hash_always_pass

Re: Making libunwind the default

> Adding a new dependency by default might be worth it all things considered. After a brief discussion on IRC I agreed to provide comparative stack traces, I'll find some time to make a couple up. Dridi ___ varnish-dev mailing list

Re: Decide Name/number of 2020-09-15 release

On Mon, Aug 31, 2020 at 8:00 AM Poul-Henning Kamp wrote: > > We're going to nail the name/number of the 2020-09-15 release at the > bugwash today. Please come prepared. The consensus is 6.5 unless we made a change that warrants a 7.0 bump, Nils will try to determine that tomorrow.

Re: Support for AARCH64

> No, I wasn't aware of this discussion. > The weekly package installed successfully now! > Thank you! And I lost track of this thread, but all's well that ends well ;-) We are looking forward to feedback regarding the weeklies, please make sure to upgrade frequently and let us know as soon as

Re: Making libunwind the default

On Mon, Jul 6, 2020 at 10:36 PM Guillaume Quintard wrote: > > Hi all, > > https://github.com/varnishcache/varnish-cache/pull/3052 was merged in > September and I was wondering if we had enough feedback (or lack thereof) to > make a decision and on making the libunwind dependency official. > >

Re: Support for AARCH64

On Wed, Jun 17, 2020 at 3:05 PM Geoff Simmons wrote: > > On 6/17/20 16:56, Nils Goroll wrote: > > On 17/06/2020 10:00, Emilio Fernandes wrote: > >> 1.1) curl -s > >> https://packagecloud.io/install/repositories/varnishcache/varnish-weekly/script.deb.sh > >> | sudo bash > > > > The fact that, with

Re: VSB_quote has gotten messy

On Mon, Apr 20, 2020 at 9:45 AM Poul-Henning Kamp wrote: > > I finally got around to look at VSB_QUOTE_GLOB feature Guillaume committed > by accident some time ago, and it doesn't work correctly as far as I > can tell, for instance, the difference between inputs: > [] > and >

Re: Support for AARCH64

> We do, in the sense that distributions do the work, but I believe the > question was about the packagecloud repos. > > Fedora is possibly a good student he, providing timely packages (Dridi > appears in 3..2..1..) but we definitely cannot expect the same thing from the > debians. *appears*

Re: Travis macos job

On Sat, Mar 7, 2020 at 8:02 PM Federico Schwindt wrote: > > Should be fixed now. Thanks! ___ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Travis macos job

Hi, Can someone with knowledge of both travis and macos have a look? Since this build it fails to find rst2man: https://travis-ci.org/varnishcache/varnish-cache/builds/653055383 Thanks, Dridi ___ varnish-dev mailing list varnish-dev@varnish-cache.org

Re: Time for release notes

On Wed, Feb 19, 2020 at 11:12 AM Dridi Boukelmoune wrote: > > Dear Varnish developers, > > It's that time of the semester already, the time where we all enjoy > revisiting what happened in the last 6 months to produce release and > upgrade notes. > > As such I'll

Time for release notes

Dear Varnish developers, It's that time of the semester already, the time where we all enjoy revisiting what happened in the last 6 months to produce release and upgrade notes. As such I'll spend the rest of today and tomorrow trying to make progress on 6.3 documentation. At this point you

Re: changelog automation?

On Thu, Jan 16, 2020 at 4:06 PM Nils Goroll wrote: > > does anyone have experience with something like > > https://github.com/hawkowl/towncrier > > at first sight, would this help with our changelog maintenance? It came to my attention recently because someone suggested that for Fedora's RPM

Re: centos_8 branch

On Mon, Dec 23, 2019 at 8:29 AM Guillaume Quintard wrote: > > Hi, > > I open that one just to work on it with Dridi being able to look on it as I > progress. but I can move it back to my repo before opening the PR if you > prefer. I thought you opened a branch to do CircleCI trial commits

2019Q4 packaging update

Greetings, Today I back-ported patches that have been living happily in the weekly branch and now we only rely on Python3 dependencies also for 6.x releases. In the process I tried Debian 10 and RHEL 8 and we can now build Varnish 6.3 on those systems without any obvious problems. The devel

Not attending the 2019-11-25 bugwash

Greetings, I will probably be in transit at the time of the bugwash so I will work with Nils to get the requested draft for #3134. If we manage to finish the proposal in time, he will speak on our behalf during the bugwash. Dridi ___ varnish-dev

Re: [VDD] VSL query extensions

Greetings, Just a quick word to say that with the release of 6.3 the following extensions are now part of the VSL query language: On Mon, May 7, 2018 at 8:08 AM Dridi Boukelmoune wrote: > > 1) Multi-line queries > > When someone wishes to capture logs for multiple reason

Re: TLS sandboxing

On Wed, Sep 4, 2019 at 8:02 AM Poul-Henning Kamp wrote: > > > In message , Nils Goroll > writ > es: > > >Yet with the H3/QUIC madness on the horizon, > > No, they actually dealt with this in the design, so that "keyless" > operation is more or less the natural architecture for QUIC. > >

Re: TLS sandboxing

Hi Nils, On Wed, Sep 4, 2019 at 7:57 AM Nils Goroll wrote: > > That is an interesting exercise, thank you, Dridi. Thanks for reading. > For TLS on TCP, I would hope that passing the session key and file descriptor > would work. Have you checked already to which extend this is supported by >

TLS sandboxing

Greetings, I have been kept forcefully awake for a few nights in a row and I let my brain fart a bunch, ran a quick experiment, and shared my thoughts on TLS support directly in varnishd. TL;DR: I think we realisticly could, if so we should. https://dridi.fedorapeople.org/post/tls-sandboxing/

Re: STRING_LIST deorbit burn completed

> Hmm, I guess I should actually grep for STRING_LIST rather than > the functions operating on it :-) I found an old ASAT in my garage and STRING_LIST usage is now gone from trunk. Dridi ___ varnish-dev mailing list varnish-dev@varnish-cache.org

Re: STRING_LIST deorbit burn completed

> Hmm, I guess I should actually grep for STRING_LIST rather than > the functions operating on it :-) I'm spoiled by git grep, it has so many killer features that I don't see myself using anything other than git for source code :) You can also grep in other branches without checking them out

Re: STRING_LIST deorbit burn completed

On Fri, Jun 21, 2019 at 1:01 PM Poul-Henning Kamp wrote: > > > In message > > , Dridi Boukelmoune writes: > >On Thu, Jun 20, 2019 at 9:29 AM Poul-Henning Kamp > >wrote: > >> > >> I have removed the remaining uses of STRING_LIST in th

Re: STRING_LIST deorbit burn completed

On Thu, Jun 20, 2019 at 9:29 AM Poul-Henning Kamp wrote: > > I have removed the remaining uses of STRING_LIST in the tree, and > made vmodtool.py be slightly annoying if it is used. Not quite: Making all in libvmod_directors

[bugwash] Retire hash_data() from VCL 4.2

Hello, I would like to add the following item to the next bugwash agenda: > 11:34 < dridi> phk: around? > 11:35 < dridi> on the topic of vcl 4.2, and considering your recent commits > 11:36 < dridi> would it make sense to retire the hash_data function in vcl > 4.2? > 11:36 < dridi> replacement

Re: VIP23 (VSL refactoring) design sketch

On Fri, May 3, 2019 at 3:07 PM Dridi Boukelmoune wrote: > > On Fri, May 3, 2019 at 12:07 PM Geoff Simmons wrote: > > > > On 5/3/19 10:51, Dridi Boukelmoune wrote: > > > > > > First we lose the ability to treat the whole record as a single sting > &

Re: VIP23 (VSL refactoring) design sketch

On Fri, May 3, 2019 at 12:07 PM Geoff Simmons wrote: > > On 5/3/19 10:51, Dridi Boukelmoune wrote: > > > > First we lose the ability to treat the whole record as a single sting > > out of the box. The client will need to reconstruct the string from > > the various f

Re: VIP23 (VSL refactoring) design sketch

On Fri, Apr 12, 2019 at 9:24 PM Poul-Henning Kamp wrote: > > > In message > , Dridi > Boukelmoune writes: > > >Interesting, for textual logs the effect of vsl_reclen is > >straightforward but how should we deal with binary records truncation? > &g

Re: on the vsl format - VIP23 (VSL refactoring) design sketch

On Fri, Apr 12, 2019 at 6:27 PM Nils Goroll wrote: > > On 12/04/2019 17:57, Dridi Boukelmoune wrote: > > The prefix, which may be optional, and by nature is supposed to be the > > first field, and coincidentally is of variable length, is a problem. > > I do not understand

Re: on the vsl format - VIP23 (VSL refactoring) design sketch

On Fri, Apr 12, 2019 at 5:08 PM Nils Goroll wrote: > > Hi, > > I spend some time pondering the VSL format, here's what I got at the moment. > > First of all, a recap of the existing format. In short: > > * a record can be an end- or wrapmarker. These are not relevant in the current > context >

Re: VIP23 (VSL refactoring) design sketch

On Fri, Apr 12, 2019 at 4:00 PM Geoff Simmons wrote: > > So I said we shouldn't get to optimizing too soon, and here I am doing > something like that. Because the discussion made me curious. > > In the attachment you'll find: > > - A first implementation of a function VSLwv() to write binary

Re: VIP23 (VSL refactoring) design sketch

On Wed, Apr 10, 2019 at 8:08 AM Nils Goroll wrote: > > Hi, > > I am +1 (or more, if I got more votes) overall, in particular, the incremental > approach seems to make a lot of sense to me. Depending on the state of the > rest > of varnish-cache core, I would try get this into production ASAP as

Re: GH006: Protected branch update failed for refs/heads/master

On Wed, Apr 3, 2019 at 2:47 PM Dridi Boukelmoune wrote: > > On Wed, Apr 3, 2019 at 2:11 PM Dridi Boukelmoune wrote: > > > > It looks like it's complaining that Travis CI needs to validate the > > attached patch first, I'm assuming via a pull request. > > >

Re: GH006: Protected branch update failed for refs/heads/master

On Wed, Apr 3, 2019 at 2:11 PM Dridi Boukelmoune wrote: > > It looks like it's complaining that Travis CI needs to validate the > attached patch first, I'm assuming via a pull request. > > Can someone else give it a try? More trivial patches

GH006: Protected branch update failed for refs/heads/master

(protected branch hook declined) > error: failed to push some refs to > 'g...@github.com:varnishcache/varnish-cache' Thanks, Dridi From f87c8e33ceeb35819e89e18dc21520f74db6e6d0 Mon Sep 17 00:00:00 2001 From: Dridi Boukelmoune Date: Wed, 3 Apr 2019 13:53:28 +0200 Subject: [PATCH] Polish

Re: Coccinelle

On Wed, Mar 27, 2019 at 8:38 AM Nils Goroll wrote: > > Re Dridi in 4edaa2836c6aba837899b78866a2567c704e336b: > > > Asking again, could we consider keeping Coccinelle patches around? > > I think it would make a lot of sense to automate coding conventions. Ideally, > make check would fail if any of

Re: Doc updates on v-c.o

On Thu, Mar 14, 2019 at 9:23 PM Geoffrey Simmons wrote: > > @Dridi, the sentence about Python under “for developers” in “Changes” implies > that python 2 is still an option. I assume that’s no longer correct? That > went in fairly early, before the decision about python 3 was made. Right, I

Re: 2019-03-15 release

On Thu, Mar 14, 2019 at 8:43 PM Poul-Henning Kamp wrote: > > Do not cut the release until I give the OK. > > I/We have a couple of i's to dots and t's to dash first. And coverity reported a bunch of things too! Dridi ___ varnish-dev mailing list

Re: Doc updates on v-c.o

On Thu, Mar 14, 2019 at 8:31 PM Poul-Henning Kamp wrote: > > > In message , Geoffrey Simmons > wr > ites: > > Seems like python3 fallout. should be fixed now Also https://varnish-cache.org/docs/ says: Documentation for the latest release 6.0 6.1 never made it in the docs :-/

Re: tabular CLI output proof of concept hack

On Tue, Feb 12, 2019 at 12:22 PM Poul-Henning Kamp wrote: > > > In message > , Dridi > Boukelmoune writes: > >> But I am also seriously wondering if we should go even further and > >> have varnishd *only* produce JSON output, and leave the render-for

Re: tabular CLI output proof of concept hack

> But I am also seriously wondering if we should go even further and > have varnishd *only* produce JSON output, and leave the render-for-humans > aspect to varnishapi or even varnishadm. Ideally implement it in libvarnish.a and expose it in libvarnishapi, with a way for varnishadm to specify a

Re: VMOD havoc generating patch

> >No, I mean when I look at the generated vcc_$VMOD_if.h, I see many > >occurrences of the $Prefix that are not guarded by VPFX() macros. > > The VPFX/VARGS/VENUM macros are mostly intended as convenience for the > files the vmod-author writes. Ack. > I didn't VPFX the prototypes to not _force_

Re: VMOD havoc generating patch

On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp wrote: > > > In message > , Dridi > Boukelmoune writes: > >On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp > >wrote: > > >I waited until my weekly CI against master would choke on this change, &

Re: VMOD havoc generating patch

On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp wrote: > > Ticket 2810 is about the names generated by vmodtool and vcc, and > while there is a good intellectual argument for getting it right, > I am a little bit worried about how much havoc that causes. > > This is a WIP patch headed in that

Re: [6.1] 2f2387038 Fix gensequences for BusyBox awk

On Wed, Nov 7, 2018 at 12:01 PM Poul-Henning Kamp wrote: > > > > Why is this fix not in -trunk ? It is: $ git branch --contains 9f50c4bd12303674890ca742ce6b9592a29e3ba9 6.1 * master But it was lost during backports. It was accidentally lost in both my 6.0 and Pål's 6.1

Re: mini benchmark vtim formatting

> So now the question is how this looks for other platforms. @All, Please send > your results! $ ./double real: 0.004972s / 10 = 49.715042ns - tst val 153899435413393.562500 mono: 0.003554s / 10 = 35.541058ns - tst val 1075376231.264834 printf %.6f: 0.059387s / 10 = 593.865160ns - tst

Re: RFC: unify directors and backends vcl interface

On Wed, Sep 19, 2018 at 12:19 PM Nils Goroll wrote: > > my example was missing the point > > On 19/09/2018 12:14, Nils Goroll wrote: > > backend "b" which you now want to layer under director "d": all instances > > of "b" > > in the vcl now need to be replaced with something like "d.backend()".

Re: CLI command vmod.tell

On Fri, May 18, 2018 at 4:07 PM, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote: > > In message > <CABoVN9CmtyVAo_CS9QK+m1Z7FY295=wanluvca5kdjqsfpu...@mail.gmail.com> > , Dridi Boukelmoune writes: > >>> vmod.tell [VCL_PATTERN:]VMODNAME argument

Re: CLI command vmod.tell

On Fri, May 18, 2018 at 11:30 AM, Poul-Henning Kamp wrote: > > In message , Geoff Simmons > write > s: > >>> vmod.tell somevcl::somevmod "bla bla bla" > > I looked a bit at this. > > There is a hurt of locking

Re: VDD summary

On Wed, May 16, 2018 at 9:20 AM, Poul-Henning Kamp wrote: > > In message >

Re: VDD summary

> => new CLI command: backend.tell args > => ... if glob matches multiple backends, error-returns are ignored > => ... Should "?" args be magic ? It occurred to me that directors listening to the CLI via a backend.tell command is a very special case that we could otherwise generalize to a

[VDD] Client-side latency

Hello everyone, I'd like to not put this item on the agenda for next Monday so I'll briefly present it here since nobody at Varnish Software thinks it will be controversial. Attendees outside of Varnish Software, please ack that this should have a de-facto "send patches" green light or we can

[VDD] VSL query extensions

Hello everyone, I'd like to not put this item on the agenda for next Monday so I'll briefly present it here since nobody at Varnish Software thinks it will be controversial. Attendees outside of Varnish Software, please ack that this should have a de-facto "send patches" green light or we can

Re: backend/director admin states

On Fri, May 4, 2018 at 9:42 AM, Poul-Henning Kamp wrote: > > The reason we have include/tbl/cli_cmds.h in the first place was > that I wanted some kind of "schema-light" for UX use, but that > didn't happen. Yes, that experiment failed, but I somehow succeeded in

Re: backend/director admin states

>>Maybe we should do that the other way around? Have all CLI commands >>reply with a JSON data structure, and CLI consumers like varnishadm, >>varnishtest or varnishd -d be able to output it in plain text (with >>this code centralized in libvarnish and exposed in libvarnishapi). > > I thought

Re: backend/director admin states

On Thu, May 3, 2018 at 1:04 PM, Poul-Henning Kamp wrote: > > In message > > , Guillaume Quintard writes: > >>All commands should have a JSON option, I reckon. > > Somebody should write more code

Re: backend/director admin states

> Best proposal for "???" seems to be "auto", even though it is not > entirely on point. > > The implementation can control its view of the health two ways > > A) Call VRT_SetHealth() and set it on the director. > (useful for probes as we know them) > > B) Provide a ->healthy() method

Re: Springtime for VDD ?

On Fri, Apr 13, 2018 at 9:00 AM, Poul-Henning Kamp wrote: > A bugwash or two ago we talked about having a VDD "soonish", > did anybody do more about that ? > > Does anybody want to do more about that ? As I'm going to be away while the VDD is being organized, I'm dumping

Re: UDS decisions

On Tue, Feb 13, 2018 at 3:47 PM, Nils Goroll wrote: > WFM, but one thing: > >> 1. We will use bogo-IP numbers for client UDS connections > > As long as we get VCL access to the accept socket name, we should not need the > uds socket path. But we should have a way to

Re: calling for a new workspace sizing concept - Re: auto-tune ws / headroom poc

On Tue, Jan 30, 2018 at 2:11 PM, Nils Goroll <sl...@schokola.de> wrote: > On 30/01/18 14:08, Dridi Boukelmoune wrote: >> Instead to new xxx_headroom knobs, why not recycle the existing workspace_xxx >> parameters to take their values _in addition to_ related parameters

Re: calling for a new workspace sizing concept - Re: auto-tune ws / headroom poc

On Tue, Jan 30, 2018 at 12:17 PM, Nils Goroll wrote: > * forbid any nested sizing parameters as in "if you tune knob a, you also need > to tune knob b" -> knob b should be replaced by a knob b' which is > independent > of knob a and any derivation should be calculated

Re: VFP and VDP configurations

>> I think the position should be mapped closer to HTTP semantics > > I think this makes too many assumptions? For example, where would security > processors go? Knowing what I know about whats possible with these things, I > think the processor universe might be bigger than the 4 categories you >

Re: VFP and VDP configurations

> - format specifiers: > > - have: > > (gzip), (plain) *1), (esi) > > - ideas: > > (br), (buffertext) *2) > > esi being a format which can contain gzip segments, but that's would > be opaque to other vfps [...] > *1) "(text)" in reza's concept

Re: VFP and VDP configurations

> So from VCL, here is how we add VFPs: > > VOID add_vfp(VFP init, ENUM position = DEFAULT); > > VFP is "struct vfp" and any VMOD can return that, thus registering itself as > a VFP. This contains all the callback and its input and output requirements. > > position is: DEFAULT, FRONT,

VIP20: Varnish ABI and packaging

Hello everyone, As requested last week, I started a VIP regarding VMODs, Varnish ABI, and packaging. While this is still incomplete, please let me know if anything needs a clarification so far. The research took me a while so I'll continue later, probably next week.

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

> OK, that should be documented though (there is other software that > works with UDSen that does in fact unlink before bind). There should be a limit to hand-holding. I have bitter memories of tracking down processes holding unlinked files around and leaving a partition with no space. The upside

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

> +1 I just had a use case for this yesterday, which might also be a general use > case: cross-container communication (in docker). Sharing a file system with a > UDS (read only) between container is safe and easy, while configuring a shared > network between containers is not. The VIP now covers

Re: VSC self-documentation

> I have a small, 500 LOC, json parser in C we can use, so that is > not going to drag in a dependency. > > If we're going to bite the JSON bullet, the other places it makes > sense to use it, is for the vcc_if.c::Vmod_Spec data structure > which explains the contents of a VMOD to VCC. > > Given

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

On Mon, May 15, 2017 at 11:41 AM, Dridi Boukelmoune <dr...@varni.sh> wrote: Hello, Making slow progress on the draft, but getting there. While gathering details from the first v6wash and the original draft, I found that named listen addresses could once again solve one of the

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

> First of all (a lesser matter): OK, we can go with commas as a > separator, with the consequence that UDS paths may not have a comma. > There is a precedent for that with -sfile. Yes, we can probably get away with no commas in file names. Also see this comment from phk:

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

>> So I say do it right from the beginning this time, and make it >> possible to use relative paths and just change the uds_path parameter >> when you have to. > > Define "when you have to", as I said earlier listen addresses are > immutable once the manager is started. That's a condition that >

Re: [master] 3d60db6 Sort out some signed/unsigned mismatches

> We'll talk about that as we approach the next release. There will > be a lot more API work before then. I already mentioned it in the #2318 ticket, I figured it belonged to the 6.0 planning ;) ___ varnish-dev mailing list

6.0 planning planning

Hello, Next Monday we're supposed to find out what we want to plan for September: https://github.com/varnishcache/varnish-cache/issues/2318 Next Monday is also May 1st, a holiday. Does Tuesday 2nd at the usual bugwash time work for everyone? Cheers, Dridi

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

> # Synopsis > Allow unix domain sockets as a listen address for Varnish (``-a`` > option) and as addresses for backends, and for use in ACLs. Obtain > credentials of the peer process connected on a UDS, such as uid and > gid, for use in VCL. Except for ACLs, I find the idea compelling so far. I

Re: sub probe_resp - VIP RFC

> # Why? No opinion on the why, I get the point and I see the benefits but no opinion. It also leaves out the non-VBE backends, although as of today I m only aware of Martin's fsbackend implementation of an out-of-tree backend. > * Add a default vcl_probe_resp sub to the builtin.vcl which

SVG change for hitpass

Hi, Here is a partial diff of the change I'm ready to push if the result is OK for everyone: -label="[...]{deliver|{304?|other?" +label="[...]{deliver or pass|{304?|other?" Please find the resulting SVG attached. It doesn't follow the usual pattern but I don't think having two boxes

Re: Commits digest

> Do I need to join the list? I'm just lazy and read the git logs, would > rather not get the spam (too much of that as it is). Dunno about your email setup but with my VS address I have no problem setting up filters to deal with lists (in my case I tag them as commits). Once you're sure it won't

Commits digest

Hello, Do the keepers of the blessed script that sends git commit emails know why sometimes commit don't land in varnish-commit? The only pattern I have identified so far is that we don't get Geoff's commits, see the archive for this month so far:

  1   2   3   >