From lkarsten at varnish-software.com Tue May 3 15:08:46 2016 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Tue, 3 May 2016 17:08:46 +0200 Subject: Varnish modules package released (Was: Re: Update on vmods and packaging) In-Reply-To: <20160304133039.GA32277@immer.varnish-software.com> References: <20151202144041.GB19950@immer.varnish-software.com> <20160304133039.GA32277@immer.varnish-software.com> Message-ID: <20160503150844.GA23674@immer.varnish-software.com> On Fri, Mar 04, 2016 at 02:30:40PM +0100, Lasse Karstensen wrote: > [crosspost to both -dev and -misc] > On Wed, Dec 02, 2015 at 03:40:42PM +0100, Lasse Karstensen wrote: [cut] > > Further down the line it is likely that we will be combining the simple > > vmods (with no third party/library dependencies) into a single > > collection source package. Updates on that will come later. > We have now made an initial release of this collection. > Tarball distribution is here: > http://files.varnish-software.com/vmod/varnish-modules-0.9.0.tar.gz For the record, tarball distribution of varnish-modules has been moved to a new and more permanent home: https://download.varnish-software.com/varnish-modules/ We'll be doing a 0.9.1 release of it soon. [cut] > 3.0 and 4.0 versions of the old vmods will be archived and made > available in a similar manner. When that has been done, the old github > projects for the vmods will be retired. The mod_index site on https://download.varnish-software.com/ also contain archived versions of assorted other vmods for 3.0 and 4.0, if anyone needs those. More will come as time permits. Git branches will be removed over time. -- Lasse Karstensen Varnish Software AS From lkarsten at varnish-software.com Tue May 3 15:21:52 2016 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Tue, 3 May 2016 17:21:52 +0200 Subject: Renewed (temporary) commitment to Jenkins (Was: Re: Continuous integration moves to Travis CI) In-Reply-To: <20151031083433.GA5176@immer.varnish-software.com> References: <20151031083433.GA5176@immer.varnish-software.com> Message-ID: <20160503152151.GB23674@immer.varnish-software.com> On Sat, Oct 31, 2015 at 09:34:34AM +0100, Lasse Karstensen wrote: > I'm changing continuous integration system for Varnish Cache to the > online Travis CI system. (https://travis-ci.org/ ) [..] > This also means that we will sunset the Jenkins CI instance that Varnish > Software has been running for the project. Basis for this is the same as > before, shifting priorities and no time to maintain it. Hi all. Varnish Software will run Jenkins and configure it for Varnish Cache CI jobs until the end of 2016. CI builds of master can be found here: https://jenkins.varnish-software.com/view/varnish-master/ This is a reversal of our previuous statement, done to keep our development efforts focused on H2. For our needs Travis works very well, I don't expect this to change. Please don't take this extension as something that will be renewed indefinitively. I hope interested members of the community will consider volunteering effort to keep Varnish running on their platform, by assisting in implementing the new CI system proposed in VIP5[1]. I'm available if anyone has questions, here or offlist. 1: https://github.com/varnishcache/varnish-cache/wiki/VIP5%3A-Remote-test-run-reporting-facility -- Lasse Karstensen Varnish Software AS From phk at phk.freebsd.dk Tue May 3 16:28:18 2016 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 03 May 2016 16:28:18 +0000 Subject: Renewed (temporary) commitment to Jenkins (Was: Re: Continuous integration moves to Travis CI) In-Reply-To: <20160503152151.GB23674@immer.varnish-software.com> References: <20151031083433.GA5176@immer.varnish-software.com> <20160503152151.GB23674@immer.varnish-software.com> Message-ID: <86104.1462292898@critter.freebsd.dk> -------- In message <20160503152151.GB23674 at immer.varnish-software.com>, Lasse Karstense n writes: >Varnish Software will run Jenkins and configure it for Varnish Cache CI >jobs until the end of 2016. Thanks a lot Lasse, it is much appreciated. >I hope interested members of the community will consider volunteering >effort to keep Varnish running on their platform, by assisting in >implementing the new CI system proposed in VIP5[1]. Yes Please! -- 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. From carlos.abalde at gmail.com Tue May 3 19:32:40 2016 From: carlos.abalde at gmail.com (Carlos Abalde) Date: Tue, 3 May 2016 21:32:40 +0200 Subject: vcl_init, VMODs & workspaces Message-ID: <8F64A004-1B72-4808-A402-887645B6D151@gmail.com> Hi all, I'm working on a VMOD (VC 4.1) and I would like to create a simple function able to return string values. You can think these strings as values of variables previously set somewhere else (e.g. environment variables) and used during vcl_init to make some decisions. This would be trivial stuff outside of vcl_init (i.e. return WS_Copy(ctx->ws, "whatever", -1)), but ctx->ws is not available during vcl_init. Is there any friendly alternative not requiring the VMOD doing explicit mallocs when returning strings, keeping track of returned pointers, and releasing them when execution of vcl_init is completed? Thanks, -- Carlos Abalde From dridi at varni.sh Wed May 4 07:13:27 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 4 May 2016 09:13:27 +0200 Subject: vcl_init, VMODs & workspaces In-Reply-To: <8F64A004-1B72-4808-A402-887645B6D151@gmail.com> References: <8F64A004-1B72-4808-A402-887645B6D151@gmail.com> Message-ID: > This would be trivial stuff outside of vcl_init (i.e. return WS_Copy(ctx->ws, "whatever", -1)), but ctx->ws is not available during vcl_init. Is there any friendly alternative not requiring the VMOD doing explicit mallocs when returning strings, keeping track of returned pointers, and releasing them when execution of vcl_init is completed? Hi Carlos, There's no escape to explicit (m)allocs, but Varnish can help you keeping track of your allocations. If you decilare an $Event [1] function in your VCC file you will receive at LOAD-time a PRIV_VCL private pointer [2] to track per-VCL data. This can be used by your module for functions that need to allocate during vcl_init{} but there's no END-OF-INIT event you could catch to free this state early, so unless you provide a specific function to do the cleaning, your free callback will be called later when the VCL is discarded. Cheers, Dridi [1] https://www.varnish-cache.org/docs/4.1/reference/vmod.html#event-functions [2] https://www.varnish-cache.org/docs/4.1/reference/vmod.html#private-pointers From carlos.abalde at gmail.com Wed May 4 07:45:34 2016 From: carlos.abalde at gmail.com (Carlos Abalde) Date: Wed, 4 May 2016 09:45:34 +0200 Subject: vcl_init, VMODs & workspaces In-Reply-To: References: <8F64A004-1B72-4808-A402-887645B6D151@gmail.com> Message-ID: <7D946260-65E6-4A4F-9325-C4703B548C0A@gmail.com> > On 04 May 2016, at 09:13, Dridi Boukelmoune wrote: > ... > > If you decilare an $Event [1] function in your VCC file you will > receive at LOAD-time a PRIV_VCL private pointer [2] to track per-VCL > data. This can be used by your module for functions that need to > allocate during vcl_init{} but there's no END-OF-INIT event you could > catch to free this state early, so unless you provide a specific > function to do the cleaning, your free callback will be called later > when the VCL is discarded. Thanks Dridi. In fact I'm considering implementing a private VMOD's workspace in PRIV_VCL using WS_Init() in order to reuse WS_* functions and keep life simple when calling VMOD functions from vcl_init and a ctx->ws is not available. I wanted to check I wasn't missing anything here :) Thanks, -- Carlos Abalde From dridi at varni.sh Wed May 4 13:41:25 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 4 May 2016 15:41:25 +0200 Subject: [master] 376bc27 Insist that tests start out with the magic string "varnishtest[:whitespace:]" In-Reply-To: References: Message-ID: On Wed, May 4, 2016 at 3:17 PM, Poul-Henning Kamp wrote: > > commit 376bc2743d373233b2e703352acb3b64e95c71ef > Author: Poul-Henning Kamp > Date: Wed May 4 13:15:34 2016 +0000 > > Insist that tests start out with the magic string "varnishtest[:whitespace:]" Hi, This commit breaks usage of shebangs or copyright notices at the beginning of test scripts. Can I send a patch to fail a test at the end if the title wasn't set? Dridi From phk at phk.freebsd.dk Wed May 4 13:45:09 2016 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 04 May 2016 13:45:09 +0000 Subject: [master] 376bc27 Insist that tests start out with the magic string "varnishtest[:whitespace:]" In-Reply-To: References: Message-ID: <68732.1462369509@critter.freebsd.dk> -------- In message , Dridi Boukelmoune writes: >On Wed, May 4, 2016 at 3:17 PM, Poul-Henning Kamp wrote: >> >> commit 376bc2743d373233b2e703352acb3b64e95c71ef >> Author: Poul-Henning Kamp >> Date: Wed May 4 13:15:34 2016 +0000 >> >> Insist that tests start out with the magic string "varnishtest[:whitespace:]" > >Hi, > >This commit breaks usage of shebangs or copyright notices at the >beginning of test scripts. > >Can I send a patch to fail a test at the end if the title wasn't set? I looked at how hard it would be to test for the first command being "varnishtest" and just did the Q&D thing instead. I would strongly prefer we insist it be the first command, so that we can use it for versioning down the road. -- 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. From dridi at varni.sh Wed May 4 13:53:58 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 4 May 2016 15:53:58 +0200 Subject: [master] 376bc27 Insist that tests start out with the magic string "varnishtest[:whitespace:]" In-Reply-To: <68732.1462369509@critter.freebsd.dk> References: <68732.1462369509@critter.freebsd.dk> Message-ID: > I would strongly prefer we insist it be the first command, so that we > can use it for versioning down the road. I'll ponder how to conciliate both. Dridi From geoff at uplex.de Wed May 4 14:28:04 2016 From: geoff at uplex.de (Geoffrey Simmons) Date: Wed, 4 May 2016 16:28:04 +0200 Subject: [master] 376bc27 Insist that tests start out with the magic string "varnishtest[:whitespace:]" In-Reply-To: <68732.1462369509@critter.freebsd.dk> References: <68732.1462369509@critter.freebsd.dk> Message-ID: <51EA4D25-D37B-46A1-BE51-17E8C8B3D468@uplex.de> Travel day today, so I can't easily pull at the moment. This is about the first command, so comment lines before 'varnishtest' don't matter? slink and I use the emacs -*- magic in a comment in the first line to set a VCL-friendly major mode. Best, Geoff Sent from my iPhone > On May 4, 2016, at 3:45 PM, Poul-Henning Kamp wrote: > > -------- > In message > , Dridi Boukelmoune writes: >>> On Wed, May 4, 2016 at 3:17 PM, Poul-Henning Kamp wrote: >>> >>> commit 376bc2743d373233b2e703352acb3b64e95c71ef >>> Author: Poul-Henning Kamp >>> Date: Wed May 4 13:15:34 2016 +0000 >>> >>> Insist that tests start out with the magic string "varnishtest[:whitespace:]" >> >> Hi, >> >> This commit breaks usage of shebangs or copyright notices at the >> beginning of test scripts. >> >> Can I send a patch to fail a test at the end if the title wasn't set? > > I looked at how hard it would be to test for the first command being > "varnishtest" and just did the Q&D thing instead. > > I would strongly prefer we insist it be the first command, so that we > can use it for versioning down the road. > > > -- > 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. > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev From dridi at varni.sh Wed May 4 14:53:00 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 4 May 2016 16:53:00 +0200 Subject: [master] 376bc27 Insist that tests start out with the magic string "varnishtest[:whitespace:]" In-Reply-To: <51EA4D25-D37B-46A1-BE51-17E8C8B3D468@uplex.de> References: <68732.1462369509@critter.freebsd.dk> <51EA4D25-D37B-46A1-BE51-17E8C8B3D468@uplex.de> Message-ID: On Wed, May 4, 2016 at 4:28 PM, Geoffrey Simmons wrote: > Travel day today, so I can't easily pull at the moment. This is about the first command, so comment lines before 'varnishtest' don't matter? For this very commit, it does (just in case it wasn't absolutely clear). Dridi From dridi at varni.sh Fri May 6 11:55:17 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Fri, 6 May 2016 13:55:17 +0200 Subject: Renewed (temporary) commitment to Jenkins (Was: Re: Continuous integration moves to Travis CI) In-Reply-To: <86104.1462292898@critter.freebsd.dk> References: <20151031083433.GA5176@immer.varnish-software.com> <20160503152151.GB23674@immer.varnish-software.com> <86104.1462292898@critter.freebsd.dk> Message-ID: >>I hope interested members of the community will consider volunteering >>effort to keep Varnish running on their platform, by assisting in >>implementing the new CI system proposed in VIP5[1]. > > Yes Please! Hello, Since Travis CI is too limited (because it does not support all Varnish supported platforms) but probably capable of building everything from source, couldn't it be used to produce comprehensive dist tarballs? People setting up CI on any platform could proceed without graphviz, python-docutils, sphinx and possibly others I'm missing. It might also be possible to skip python altogether if VMOD interfaces are generated at dist-time. Obviously some work needs to be done to produce proper tarballs (eg. varnish-${BRANCH}-${SHORTCOMMIT}.tar.gz) but it could also remove some packaging burden for everyone else. Best, Dridi From phk at phk.freebsd.dk Tue May 10 20:05:52 2016 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 10 May 2016 20:05:52 +0000 Subject: library cleanup Message-ID: <65890.1462910752@critter.freebsd.dk> I did som cleanup in the varnishapi library this morning, and I want the VMOD writers to pay a bit of attention. VUT, VTIM, VSB, VAS and VCS are now partially exposed by libvarnishapi. I have not exposed everything in them (yet), only the bits needed to compile the tools in the tree (varnishlog/ncsa/...) Should we expose all of these function sets ? Should we also expose VPF, VSS, VSA, VTCP ? I may also rename the SHA256 to VSHA256 in order to stick strictly to the V* namespace... Input, comments... -- 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. From dridi at varni.sh Wed May 11 06:58:35 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 11 May 2016 08:58:35 +0200 Subject: library cleanup In-Reply-To: <65890.1462910752@critter.freebsd.dk> References: <65890.1462910752@critter.freebsd.dk> Message-ID: On Tue, May 10, 2016 at 10:05 PM, Poul-Henning Kamp wrote: > I did som cleanup in the varnishapi library this morning, and I want > the VMOD writers to pay a bit of attention. Does it matter that much for VMODs? They automatically link to varnish/varnishapi symbols via varnishd and most headers are already $(make install)'ed. This is very interesting for shmlog tools writers, especially now that VUT is part of libvarnishapi! Dridi From phk at phk.freebsd.dk Wed May 11 14:51:02 2016 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 11 May 2016 14:51:02 +0000 Subject: library cleanup In-Reply-To: References: <65890.1462910752@critter.freebsd.dk> Message-ID: <10922.1462978262@critter.freebsd.dk> -------- In message , Dridi Boukelmoune writes: >On Tue, May 10, 2016 at 10:05 PM, Poul-Henning Kamp wrote: >> I did som cleanup in the varnishapi library this morning, and I want >> the VMOD writers to pay a bit of attention. > >Does it matter that much for VMODs? They automatically link to >varnish/varnishapi symbols via varnishd and most headers are already >$(make install)'ed. > >This is very interesting for shmlog tools writers, especially now that >VUT is part of libvarnishapi! Good points. -- 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. From lkarsten at varnish-software.com Tue May 24 08:16:16 2016 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Tue, 24 May 2016 10:16:16 +0200 Subject: Backport labels added to issues Message-ID: <20160524081615.GA13694@immer.varnish-software.com> Hi all. I've created some new labels in varnishcache/varnish-cache/ now. They are: backport-review-4.0 backport-review-4.1 needs-backport-4.0 needs-backport-4.1 When a issue is closed (minus exceptions, see below) the backport-review-nnn labels will be added automatically. After the backport team has reviewed it, the label will be removed from the (still closed) issue. If the bug doesn't apply to the version, we are done and can forget about it for now. If it needs a backport, the "needs-backport-nnn" label will be added manually. When it is commited, that label is removed manually. A issue will not receive backport labeling if it has "duplicate" or "packaging". We'll extend this as we get more experience on the false positives. -- Lasse Karstensen Varnish Software AS