--------
In message <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com>, Frederic Lecaille writes:
>I hope everything is going well on your side.
Well, getting better: One of my close friends died from stomach-cancer
right before X-mas and that threw all plans askew.
>So, if you need some help to make vtest project progress, please
>do not hesitate to ask.
I think what we need most right now, is to decide what shape vtest
should take?
I want to stress that I want this to be a collective decision,
so don't take anything I write here as edict or diktat.
Personally I am not very keen on turning vtest a "real" project
with releases, package-building and all that, because it would cause
me a lot of work which I don't think brings enough advantages.
The problem for me is that vtc_varnish has a very incestuos
relationship with varnish internals, internals which we do not want
to turn into documented or even open APIs, and that means that
vtc_varnish and varnishd must match versions.
A stand-alone vtest-package would either need to be compiled against
a specific version of varnish, or have some way to dynamically load
vtc_varnish from from the varnish source/package it is being used
against.
But that just moves the problem to the other side of the line, where
we need to open the internals of vtest up as a documented and
versioned API...
Some day (H3?) all that work may make sense, but I don't feel we
are there yet, at least not as far as cost/benefit is concerned.
My suggestion for now, is to let vtest live as a "source code
library" on github and not build and distribute it as stand-alone
packages.
Instead it will be up to the projects which use it to import
and build in their own projects.
That way HAproxy and leave vtc_varnish out of their compilation so
varnish does not become a build-dependency (or you can conditionally
compile vtc_varnish in, if it is already there.)
And we can compile it in Varnish including vtc_varnish, and include
vtc_haproxy in similar fashion. (actually, compilation of
vtc_haproxy does not need haproxy to be installed, does it ?)
We should still provide a Makefile in the vtest github project which
compiles as much as possible (ie: vtc_varnish if it can find varnish
installed), that will make work on the shared sources easier for
all of us.
If we decide to do things that way, maybe you should call your
compiled version something like "hatest", while we stick with
"varnishtest", so we can reserve the "vtest" name for the future
runtime-extensible all-singing-and-dancing thing ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
In message <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com>, Frederic Lecaille writes:
>I hope everything is going well on your side.
Well, getting better: One of my close friends died from stomach-cancer
right before X-mas and that threw all plans askew.
>So, if you need some help to make vtest project progress, please
>do not hesitate to ask.
I think what we need most right now, is to decide what shape vtest
should take?
I want to stress that I want this to be a collective decision,
so don't take anything I write here as edict or diktat.
Personally I am not very keen on turning vtest a "real" project
with releases, package-building and all that, because it would cause
me a lot of work which I don't think brings enough advantages.
The problem for me is that vtc_varnish has a very incestuos
relationship with varnish internals, internals which we do not want
to turn into documented or even open APIs, and that means that
vtc_varnish and varnishd must match versions.
A stand-alone vtest-package would either need to be compiled against
a specific version of varnish, or have some way to dynamically load
vtc_varnish from from the varnish source/package it is being used
against.
But that just moves the problem to the other side of the line, where
we need to open the internals of vtest up as a documented and
versioned API...
Some day (H3?) all that work may make sense, but I don't feel we
are there yet, at least not as far as cost/benefit is concerned.
My suggestion for now, is to let vtest live as a "source code
library" on github and not build and distribute it as stand-alone
packages.
Instead it will be up to the projects which use it to import
and build in their own projects.
That way HAproxy and leave vtc_varnish out of their compilation so
varnish does not become a build-dependency (or you can conditionally
compile vtc_varnish in, if it is already there.)
And we can compile it in Varnish including vtc_varnish, and include
vtc_haproxy in similar fashion. (actually, compilation of
vtc_haproxy does not need haproxy to be installed, does it ?)
We should still provide a Makefile in the vtest github project which
compiles as much as possible (ie: vtc_varnish if it can find varnish
installed), that will make work on the shared sources easier for
all of us.
If we decide to do things that way, maybe you should call your
compiled version something like "hatest", while we stick with
"varnishtest", so we can reserve the "vtest" name for the future
runtime-extensible all-singing-and-dancing thing ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev