From carlos.abalde at gmail.com Mon Sep 10 10:53:02 2018 From: carlos.abalde at gmail.com (Carlos Abalde) Date: Mon, 10 Sep 2018 12:53:02 +0200 Subject: PRIV_TASK and PRIV_TOP changes in 6.1 Message-ID: <6D9AFE44-4BEC-4B34-890A-4DE7F317A83B@gmail.com> Hi all, I assume https://github.com/varnishcache/varnish-cache/commit/f03948f48445be4dbea5f389ac4168b4a6befc6c is related with the PRIV_TASK and PRIV_TOP change mentioned in section 'Changes for developers' in https://github.com/varnishcache/varnish-cache/blob/master/doc/sphinx/whats-new/upgrading-6.1.rst. Problem is I'm not sure I'm understanding what are the implications of that change for VMOD developers. For example, I checked implementation of xyzzy_test_priv_task() in lib/libvmod_debug/vmod_debug.c, both in 'master' and 'varnish-6.0.1', and I don't see any relevant changes: no assertions on 'priv', 'priv->priv' initialized as expected, etc. It seems I'm missing something here but I don't know what. Any clues? :) Thanks, -- Carlos Abalde From geoff at uplex.de Mon Sep 10 10:58:55 2018 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 10 Sep 2018 12:58:55 +0200 Subject: PRIV_TASK and PRIV_TOP changes in 6.1 In-Reply-To: <6D9AFE44-4BEC-4B34-890A-4DE7F317A83B@gmail.com> References: <6D9AFE44-4BEC-4B34-890A-4DE7F317A83B@gmail.com> Message-ID: On 09/10/2018 12:53 PM, Carlos Abalde wrote: > > I assume > https://github.com/varnishcache/varnish-cache/commit/f03948f48445be4dbea5f389ac4168b4a6befc6c > is related with the PRIV_TASK and PRIV_TOP change mentioned in section > 'Changes for developers' in > https://github.com/varnishcache/varnish-cache/blob/master/doc/sphinx/whats-new/upgrading-6.1.rst. The draft in 'Upgrading for 6.1' is currently very new (since yesterday), has not been reviewed and could very well be in error. We're about to have bugwash (in just a few minutes) and will probably talk about reviewing and polishing the release notes, among other things. We'll have quality-assured documentation by the time the release goes public a week from today. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From slink at schokola.de Tue Sep 11 07:36:58 2018 From: slink at schokola.de (Nils Goroll) Date: Tue, 11 Sep 2018 09:36:58 +0200 Subject: PRIV_TASK and PRIV_TOP changes in 6.1 In-Reply-To: <6D9AFE44-4BEC-4B34-890A-4DE7F317A83B@gmail.com> References: <6D9AFE44-4BEC-4B34-890A-4DE7F317A83B@gmail.com> Message-ID: <24aaf739-5cae-e55b-d698-a83cd9db0164@schokola.de> On 10/09/18 12:53, Carlos Abalde wrote: > Problem is I'm not sure I'm understanding what are the implications of that change for VMOD developers. now documented here: https://github.com/varnishcache/varnish-cache/commit/2423a578478c69cc78e52c8900a5c68797e9f998 in short: there is no change from a vmod developer perspective. From geoff at uplex.de Tue Sep 11 07:40:17 2018 From: geoff at uplex.de (Geoff Simmons) Date: Tue, 11 Sep 2018 09:40:17 +0200 Subject: PRIV_TASK and PRIV_TOP changes in 6.1 In-Reply-To: <24aaf739-5cae-e55b-d698-a83cd9db0164@schokola.de> References: <6D9AFE44-4BEC-4B34-890A-4DE7F317A83B@gmail.com> <24aaf739-5cae-e55b-d698-a83cd9db0164@schokola.de> Message-ID: <3caac863-2db7-ff17-66f4-4e1714d7fe27@uplex.de> On 09/11/2018 09:36 AM, Nils Goroll wrote: > On 10/09/18 12:53, Carlos Abalde wrote: >> Problem is I'm not sure I'm understanding what are the >> implications of that change for VMOD developers. > > now documented here: > > https://github.com/varnishcache/varnish-cache/commit/2423a578478c69cc78e52c8900a5c68797e9f998 > > in short: there is no change from a vmod developer perspective. I think it's wise for a VMOD implementation to check if PRIV_* parameters are NULL, in case of the out-of-workspace condition. -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From slink at schokola.de Tue Sep 11 08:18:05 2018 From: slink at schokola.de (Nils Goroll) Date: Tue, 11 Sep 2018 10:18:05 +0200 Subject: PRIV_TASK and PRIV_TOP changes in 6.1 In-Reply-To: <3caac863-2db7-ff17-66f4-4e1714d7fe27@uplex.de> References: <6D9AFE44-4BEC-4B34-890A-4DE7F317A83B@gmail.com> <24aaf739-5cae-e55b-d698-a83cd9db0164@schokola.de> <3caac863-2db7-ff17-66f4-4e1714d7fe27@uplex.de> Message-ID: On 11/09/18 09:40, Geoff Simmons wrote: > I think it's wise for a VMOD implementation to check if PRIV_* > parameters are NULL, in case of the out-of-workspace condition. We had discussed that option and decided against it. VCC guarantees that the PRIV_* parameters are never NULL - a VCL failure happens before calling the vmod function if a PRIV Parameter would be NULL. Nils From slink at schokola.de Wed Sep 19 10:14:16 2018 From: slink at schokola.de (Nils Goroll) Date: Wed, 19 Sep 2018 12:14:16 +0200 Subject: RFC: unify directors and backends vcl interface Message-ID: <695e87fe-cd99-96b0-07b0-22f2cf916c5f@schokola.de> backends and directors are both represented as VCL_BACKEND aka struct director, yet VCL authors need to differentiate between them: * backends are represented directly as the BACKEND type * directors are represented as vmod objects, for which a method (.backend() by convention only) returns a BACKEND I don't see why we would need to make this distinction and getting rid of it would simplify VCL code generation and -refactoring. Consider the case having 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()". I see two obvious options to simplify: * implement backends as vmod objects and/or * add a default getter method for objects such that d == d.backend() Opinions? From slink at schokola.de Wed Sep 19 10:18:57 2018 From: slink at schokola.de (Nils Goroll) Date: Wed, 19 Sep 2018 12:18:57 +0200 Subject: RFC: unify directors and backends vcl interface In-Reply-To: <695e87fe-cd99-96b0-07b0-22f2cf916c5f@schokola.de> References: <695e87fe-cd99-96b0-07b0-22f2cf916c5f@schokola.de> Message-ID: <783d3a8c-e304-5c34-990d-a7ed8def2cc3@schokola.de> 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()". ... while, if we had a common accessor, b could be renamed to bb and the director be called b. From dridi at varni.sh Wed Sep 19 17:08:47 2018 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 19 Sep 2018 19:08:47 +0200 Subject: RFC: unify directors and backends vcl interface In-Reply-To: <783d3a8c-e304-5c34-990d-a7ed8def2cc3@schokola.de> References: <695e87fe-cd99-96b0-07b0-22f2cf916c5f@schokola.de> <783d3a8c-e304-5c34-990d-a7ed8def2cc3@schokola.de> Message-ID: 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()". > > ... while, if we had a common accessor, b could be renamed to bb and the > director be called b. That won't work when .backend() takes arguments *cough* hash *cough*. I think the confusion is mostly that we make an amalgam of the VMOD object and the underlying director. I'm not strictly against adding some magic to VCL, in this case saying that having a no-arg method returning a VCL_BACKEND could be used automagically when casting an "expression" to a backend and even enforce that the name of the no-arg method is .backend(). I suggested in the past that "vmod-object ~ arg" syntax could automatically be turned into "vmod-object.match(arg)" when we have a matching (pun intended) "BOOL .match(SINGLE-ARG)" method. In case it's not clear, I think it's a good idea, and I'm merely discussing caveats to consider. Mainly, disambiguation. Dridi From phk at phk.freebsd.dk Wed Sep 19 20:20:36 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 19 Sep 2018 20:20:36 +0000 Subject: RFC: unify directors and backends vcl interface In-Reply-To: References: <695e87fe-cd99-96b0-07b0-22f2cf916c5f@schokola.de> <783d3a8c-e304-5c34-990d-a7ed8def2cc3@schokola.de> Message-ID: <3238.1537388436@critter.freebsd.dk> -------- In message , Dridi Boukelmoune writes: >I think the confusion is mostly that we make an amalgam of the VMOD >object and the underlying director. [...] Well, there is a lot of ways to get confused, and I have yet to find any obvious ways to make all the confusion go away. I already thought about the hidden "are you a backend?" method Dridi proposes, but it opens a lot of corner cases and becomes quite complicated. Most of the ideas I have toyed with, which supressed a *lot* of confusion is stuff which forces a major version release, and I'm not quite sure I'm ready for that yet. One thing I *really* miss right now is some serious high-end benchmarking, to inform decisions about how much CPU we can afford to "waste" on stuff like this. -- 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 slink at schokola.de Thu Sep 20 07:45:59 2018 From: slink at schokola.de (Nils Goroll) Date: Thu, 20 Sep 2018 09:45:59 +0200 Subject: RFC: unify directors and backends vcl interface In-Reply-To: <3238.1537388436@critter.freebsd.dk> References: <695e87fe-cd99-96b0-07b0-22f2cf916c5f@schokola.de> <783d3a8c-e304-5c34-990d-a7ed8def2cc3@schokola.de> <3238.1537388436@critter.freebsd.dk> Message-ID: On 19/09/2018 22:20, Poul-Henning Kamp wrote: > One thing I *really* miss right now is some serious high-end > benchmarking, to inform decisions about how much CPU we can afford > to "waste" on stuff like this. Apologies for playing this back to you, but you seem to imply that we would need some kind of run-time method resolution and this is in no way what I had been thinking of when I proposed to dedicate an "object accessor" method. Re Dridi: On 19/09/2018 19:08, Dridi Boukelmoune wrote: > That won't work when .backend() takes arguments *cough* hash *cough*. Sure, I am aware that the simple text replacement example is a special case - and it was only that, an example. > I suggested in the past that "vmod-object ~ arg" syntax could automatically > be turned into "vmod-object.match(arg)" when we have a matching (pun > intended) "BOOL .match(SINGLE-ARG)" method. +1 Nils From phk at phk.freebsd.dk Thu Sep 20 08:12:05 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 20 Sep 2018 08:12:05 +0000 Subject: RFC: unify directors and backends vcl interface In-Reply-To: References: <695e87fe-cd99-96b0-07b0-22f2cf916c5f@schokola.de> <783d3a8c-e304-5c34-990d-a7ed8def2cc3@schokola.de> <3238.1537388436@critter.freebsd.dk> Message-ID: <5434.1537431125@critter.freebsd.dk> -------- In message , Nils Goroll writes: >On 19/09/2018 22:20, Poul-Henning Kamp wrote: >> One thing I *really* miss right now is some serious high-end >> benchmarking, to inform decisions about how much CPU we can afford >> to "waste" on stuff like this. > >Apologies for playing this back to you, but you seem to imply that we would need >some kind of run-time method resolution and this is in no way what I had been >thinking of when I proposed to dedicate an "object accessor" method. I was talking in context of the broader backend-issues, refcounting and all that. -- 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 phk at phk.freebsd.dk Sat Sep 22 17:34:17 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 22 Sep 2018 17:34:17 +0000 Subject: Divorcing varnishtest from varnish-cache Message-ID: <71064.1537637657@critter.freebsd.dk> We discussed this at our developer summit in Hamburg yesterday and I had made some experiments on the train down there. The suggested plan right now is: 1. Try to gain control of the empty 'vtest' account on github I've sent them a message. (Do we know any insiders ?) Alternative name suggestions if this fails are most welcome. 2. Create a vtest repository which contains: ./README ./Makefile ./lib/ (slimmed down) files from lib/libvarnish ./src/ bin/varnishtest/*.[ch] ./tests/ a?????.vtc tests, purged from varnishd usage My in-train test got it down to 29kLOC. 3. Give developer access to interested & trustworthy parties We should probably define an informal review/design process, so that nobody drags the carpet under somebody else by accident. 4. No binary packages/releases will be built at this time HAproxy and Varnish-Cache can/will import by whatever means from the new common 'vtest' project, and build vtest the way which works best for their project. (V-C obviously have some backwards compat issues) 5. See where that takes us. -- 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 w at 1wt.eu Sat Sep 22 18:17:39 2018 From: w at 1wt.eu (Willy Tarreau) Date: Sat, 22 Sep 2018 20:17:39 +0200 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <71064.1537637657@critter.freebsd.dk> References: <71064.1537637657@critter.freebsd.dk> Message-ID: <20180922181739.GA7886@1wt.eu> Hi Poul-Henning! On Sat, Sep 22, 2018 at 05:34:17PM +0000, Poul-Henning Kamp wrote: > We discussed this at our developer summit in Hamburg yesterday > and I had made some experiments on the train down there. > > The suggested plan right now is: > > 1. Try to gain control of the empty 'vtest' account on github > I've sent them a message. (Do we know any insiders ?) > Alternative name suggestions if this fails are most welcome. Unfortunately they don't have much balls overthere. We've had quite some difficulties recovering the haproxy account. All they could do was to point us to other projects the same contributor contributed to hoping that we could contact him opening issues overthere :-/ In the end we were lucky because the guy is very friendly to haproxy and was just never reading his emails, so once he found them he moved around and let us install our stuff there. So I woudln't count on any help from github. I think they are very strict regarding any form of information leak, which can be understandable given the numerous projects they host. I'd suggest to try to contact the vtest account owner directly. If that fails, maybe leaving it under the varnish account would still make sense since that's where it comes from and it's not a secret. > 2. Create a vtest repository which contains: > > ./README > ./Makefile > ./lib/ > (slimmed down) files from lib/libvarnish > ./src/ > bin/varnishtest/*.[ch] > ./tests/ > a?????.vtc tests, purged from varnishd usage > > My in-train test got it down to 29kLOC. Quite good! > 3. Give developer access to interested & trustworthy parties > > We should probably define an informal review/design process, so > that nobody drags the carpet under somebody else by accident. Probably. > 4. No binary packages/releases will be built at this time > > HAproxy and Varnish-Cache can/will import by whatever > means from the new common 'vtest' project, and build > vtest the way which works best for their project. > (V-C obviously have some backwards compat issues) I think that emitting a 1.0 version "soon" could boost adoption and send a signal that it's good enough for what all of us currently need. It seems to me that the utility is already usable on both projects so it might be a good way to tell the community "look, now it's born, it's reliable, if it finds bugs they're more likely in the project that uses it than in the utility itself". With a bit of luck, other projects could be attracted. Thanks for the update! Willy From geoff at uplex.de Mon Sep 24 10:04:04 2018 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 24 Sep 2018 12:04:04 +0200 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <20180922181739.GA7886@1wt.eu> References: <71064.1537637657@critter.freebsd.dk> <20180922181739.GA7886@1wt.eu> Message-ID: On 9/22/18 20:17, Willy Tarreau wrote: >> >> 1. Try to gain control of the empty 'vtest' account on github >> I've sent them a message. (Do we know any insiders ?) >> Alternative name suggestions if this fails are most welcome. > > Unfortunately they don't have much balls overthere. If this becomes too much trouble, some searches just showed me that "p-test", "pxytest" and "prox-test" (meant to suggest "proxy test") are not in use at github. "proxytest" and "proxy_test" are taken by both repos and users, not too surprisingly, as are "proxtest", "ptest" and "proxitest". phk wanted something with "v" to motivate the ".vtc" extension. The explanation for that might have to be just: "it's legacy, don't ask". Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From phk at phk.freebsd.dk Mon Sep 24 10:39:38 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 24 Sep 2018 10:39:38 +0000 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <71064.1537637657@critter.freebsd.dk> References: <71064.1537637657@critter.freebsd.dk> Message-ID: <46648.1537785578@critter.freebsd.dk> -------- In message <71064.1537637657 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: >1. Try to gain control of the empty 'vtest' account on github > I've sent them a message. (Do we know any insiders ?) > Alternative name suggestions if this fails are most welcome. OK, color me amazed... I now have the @vtest account on github. -- 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 phk at phk.freebsd.dk Mon Sep 24 10:50:53 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 24 Sep 2018 10:50:53 +0000 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <46648.1537785578@critter.freebsd.dk> References: <71064.1537637657@critter.freebsd.dk> <46648.1537785578@critter.freebsd.dk> Message-ID: <46770.1537786253@critter.freebsd.dk> -------- I guess my age is showing, as I almost forgot the most important thing: 0. We need a cute 'vtest' logo :-) -- 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 w at 1wt.eu Mon Sep 24 11:30:14 2018 From: w at 1wt.eu (Willy Tarreau) Date: Mon, 24 Sep 2018 13:30:14 +0200 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <46648.1537785578@critter.freebsd.dk> References: <71064.1537637657@critter.freebsd.dk> <46648.1537785578@critter.freebsd.dk> Message-ID: <20180924113014.GB9322@1wt.eu> On Mon, Sep 24, 2018 at 10:39:38AM +0000, Poul-Henning Kamp wrote: > -------- > In message <71064.1537637657 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: > > >1. Try to gain control of the empty 'vtest' account on github > > I've sent them a message. (Do we know any insiders ?) > > Alternative name suggestions if this fails are most welcome. > > OK, color me amazed... I now have the @vtest account on github. Oh, excellent! Willy From w at 1wt.eu Mon Sep 24 12:17:56 2018 From: w at 1wt.eu (Willy Tarreau) Date: Mon, 24 Sep 2018 14:17:56 +0200 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <20180924140433.68447f5c@barghest.suse.de> References: <71064.1537637657@critter.freebsd.dk> <20180924140433.68447f5c@barghest.suse.de> Message-ID: <20180924121756.GC9346@1wt.eu> Hi Marcus, On Mon, Sep 24, 2018 at 02:04:33PM +0200, Marcus R?ckert wrote: > On Sat, 22 Sep 2018 17:34:17 +0000 > "Poul-Henning Kamp" wrote: > > 4. No binary packages/releases will be built at this time > > > > HAproxy and Varnish-Cache can/will import by whatever > > means from the new common 'vtest' project, and build > > vtest the way which works best for their project. > > (V-C obviously have some backwards compat issues) > > >From a distribution standpoint ... why not make it into a library from > the beginning to avoid code duplication? It would in my opinion cause more code duplication in fact. It really is a complete utility already and splitting it would force both projects to reimplement part of the glue needed to use the common parts. That would create undesired dependencies and conflicts for no benefit. I'm pretty sure that soon what will be needed is just "git clone github:/vtest/vtest", configure, make and then you're done. That's very convenient for a developer. Cheers, Willy From phk at phk.freebsd.dk Mon Sep 24 15:10:54 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 24 Sep 2018 15:10:54 +0000 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <20180924140433.68447f5c@barghest.suse.de> References: <71064.1537637657@critter.freebsd.dk> <20180924140433.68447f5c@barghest.suse.de> Message-ID: <10601.1537801854@critter.freebsd.dk> -------- In message <20180924140433.68447f5c at barghest.suse.de>, Marcus =?UTF-8?B?UsO8Y2tlcnQ=?= writes: >On Sat, 22 Sep 2018 17:34:17 +0000 >"Poul-Henning Kamp" wrote: >> 4. No binary packages/releases will be built at this time >> >> HAproxy and Varnish-Cache can/will import by whatever >> means from the new common 'vtest' project, and build >> vtest the way which works best for their project. >> (V-C obviously have some backwards compat issues) > >From a distribution standpoint ... why not make it into a library from >the beginning to avoid code duplication? Because I want to see where this takes us as we gain some hands-on experience with sharing code, rather than try to plot out a course which may not be relevant to our needs. -- 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 phk at phk.freebsd.dk Tue Sep 25 20:57:00 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 25 Sep 2018 20:57:00 +0000 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <20180924140433.68447f5c@barghest.suse.de> References: <71064.1537637657@critter.freebsd.dk> <20180924140433.68447f5c@barghest.suse.de> Message-ID: <33540.1537909020@critter.freebsd.dk> -------- I have made a first export/import of VTest now: https://github.com/vtest/VTest The Makefile is very rudimentary and mostly so that I could see that the convert.sh script does something sensible. Let the experiments start... Poul-Henning -- 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 w at 1wt.eu Tue Sep 25 21:49:10 2018 From: w at 1wt.eu (Willy Tarreau) Date: Tue, 25 Sep 2018 23:49:10 +0200 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <33540.1537909020@critter.freebsd.dk> References: <71064.1537637657@critter.freebsd.dk> <20180924140433.68447f5c@barghest.suse.de> <33540.1537909020@critter.freebsd.dk> Message-ID: <20180925214910.GA10546@1wt.eu> On Tue, Sep 25, 2018 at 08:57:00PM +0000, Poul-Henning Kamp wrote: > -------- > > I have made a first export/import of VTest now: > > https://github.com/vtest/VTest > > The Makefile is very rudimentary and mostly so that I could see that > the convert.sh script does something sensible. > > Let the experiments start... A very (too) quick check gives me this : python3 src/huffman_gen.py src/tbl/vhp_huffman.h > src/vtc_h2_dectbl.h /bin/sh: python3: command not found I modified the makefile to directly execute "src/huffman_gen.py" which apparently uses "usr/bin/env python" to find it and it went OK for this part (copy-pasted below for illustration, tabs/spaces mangled) : diff --git a/Makefile b/Makefile index a51ea1f..e3a008e 100644 --- a/Makefile +++ b/Makefile @@ -11,7 +11,7 @@ vtest: \ src/sequences src/gensequences \ src/huffman_gen.py src/tbl/vhp_huffman.h awk -f src/gensequences src/sequences > src/teken_state.h - python3 src/huffman_gen.py src/tbl/vhp_huffman.h > src/vtc_h2_dectbl.h + src/huffman_gen.py src/tbl/vhp_huffman.h > src/vtc_h2_dectbl.h ${CC} \ -o vtest \ -I src \ But it failed slightly later : src/vtc_varnish.c:46:22: fatal error: vapi/vsc.h: No such file or directory I indeed don't have this file at all in the repo. However that's all for me for this evening. Thanks! Willy From darix at nordisch.org Mon Sep 24 12:04:33 2018 From: darix at nordisch.org (Marcus =?UTF-8?B?UsO8Y2tlcnQ=?=) Date: Mon, 24 Sep 2018 14:04:33 +0200 Subject: Divorcing varnishtest from varnish-cache In-Reply-To: <71064.1537637657@critter.freebsd.dk> References: <71064.1537637657@critter.freebsd.dk> Message-ID: <20180924140433.68447f5c@barghest.suse.de> On Sat, 22 Sep 2018 17:34:17 +0000 "Poul-Henning Kamp" wrote: > 4. No binary packages/releases will be built at this time > > HAproxy and Varnish-Cache can/will import by whatever > means from the new common 'vtest' project, and build > vtest the way which works best for their project. > (V-C obviously have some backwards compat issues) From a distribution standpoint ... why not make it into a library from the beginning to avoid code duplication? -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org