On Mon, Sep 23, 2024 at 2:02 PM Poul-Henning Kamp wrote:
>
> In order to improve throughput of bugwashes, I'll start to assign
> "homework" for then, tickets which everybody is expected to be
> ready to handle.
>
> For next week, the homework is ticket 3976: Pluggable Acceptors.
I have relayed th
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. T
> 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 ag
> 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
___
> > > 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 the
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
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 +41
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
> https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6m5FSuTtQOxGY1oSL52Ydbrw-3D-3D
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
>
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 no
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 ?
> >
>
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
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 ?
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
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 wo
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
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 nu
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
m
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 ini
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 PM
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:
>
&
> OK ... hmmm. My experience has been that the information available in a
> panic's stack trace, or to gdb for a coredump, has been relatively
> barren. The binary isn't stripped, so you can see function names, but
> that's about it, everything else is mostly question marks and hex digits.
>
> Asse
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}
> Pr
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:
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 as
Static salutations,
We haven't had a Coverity Scan build since Dec 6th despite having a
Travis cron job responsible for submitting builds, and allegedly
submitting them successfully.
See for example the latest job:
https://travis-ci.org/github/varnishcache/varnish-cache/builds/752636440#L1209-L1
> 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
varnish-dev@varnish-c
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.
Coincidentall
> 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 so
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.
>
> Al
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
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
> [
> 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*
F
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
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
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&#
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 might
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 chan
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&error commits
On Wed, Dec 11, 2019 at 11:37 AM Dridi Boukelmoune
wrote:
>
>
> commit 4ca376fab22e126b4e0a89d1773c379d1af23d0e
> Author: Dridi Boukelmoune
> Date: Tue Mar 12 10:30:35 2019 +0100
>
> Switch to python3 in all our scripts shebangs
This is a back-port of a commit from w
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 might
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 mailin
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 reasons, they
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.
>
>
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
> exi
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/
I
> 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
https:/
> 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 loca
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
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
###
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 w
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
> >
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
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?
>
>
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
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
>
>
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 field
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 I
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.
>
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 trivi
master -> 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 +
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
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 did
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
varnis
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 :-/
Drid
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-hu
> 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 wi
> >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_
On Mon, Feb 4, 2019 at 10:29 PM Poul-Henning Kamp wrote:
>
>
> In message
> , Dridi
> Boukelmoune writes:
> >On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp wrote:
>
> >It seems incomplete though, currently the $Prefix is applied all over
> >the
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,
&
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 di
> But it was lost during backports. It was accidentally lost in both my
> 6.0 and Pål's 6.1 backports.
I guess both Pål and I lost it because it was also lost in the mater branch:
$ git grep l_prefix_name -- bin/varnishtest/gensequences
bin/varnishtest/gensequences:
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 ba
> 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
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()".
>
On Fri, May 18, 2018 at 4:07 PM, Poul-Henning Kamp wrote:
>
> In message
>
> , Dridi Boukelmoune writes:
>
>>> vmod.tell [VCL_PATTERN:]VMODNAME arguments [...]
>
>>Can we also pass a nonce to the VMOD? So that "global" actions can be
&
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 issues for VMOD writers trying to do
> anything smart, but trivial stuff
On Wed, May 16, 2018 at 9:20 AM, Poul-Henning Kamp wrote:
>
> In message
>
> , Dridi Boukelmoune writes:
>>> => new CLI command: backend.tell args
>>> => ... if glob matches multiple backends, error-returns are ignored
>>> => ... Should
> => 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 vmod.cm
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 disc
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 disc
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 doing
something similar
>>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 about
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 for it then, I reckon :-)
Maybe we should do that the other way around? Have all CLI comman
> 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 whic
> I would also suggest ISO 8601 format for the 'Last change' column, to
> make it more easily parseable:
>
> 2018-05-02T13:22:10Z
>
> Then every whitespace-separated field corresponds to a data column.
Very good point, and this format is a natural fit for sorting!
Dridi
__
> Illustrated example: varnishadm backend.list output
>
> Backend name Admin Probe Last change
> boot.b1 probe 0/8 badWed, 02 May 2018 13:22:10
> GMT
> boot.b2 probe 8/8 good Wed, 02 May 2018 13:22:10
> GMT
> boot
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
here the topics I'd like
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 differentiate between
> /untrus
On Tue, Jan 30, 2018 at 2:11 PM, Nils Goroll 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 and maybe
>> docum
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 automatically.
>
> * ma
>> 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
>
> - 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
Or
> 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, MIDDL
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.
https://github.com/varnishcac
> 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
> +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
> Thoughts?
I finally completed the draft, modulus open questions:
https://github.com/varnishcache/varnish-cache/wiki/VIP-17:-Enable-Unix-domain-sockets-for-listen-and-backend-addresses/_compare/caa8cf86af2ab1e8c37f2a80bee29f4a16333898...295e902cbdef98aa28f5cacf171f433c5a48e8e7
Ready for the nex
> 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 th
On Mon, May 15, 2017 at 11:41 AM, Dridi Boukelmoune 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 issues.
In this case, that would
1 - 100 of 333 matches
Mail list logo
