varnishctl?

[Dridi Boukelmoune]

On Tue, Jan 28, 2014 at 8:07 AM, Tollef Fog Heen
<tfheen at varnish-software.com> wrote:
> ]] Dridi Boukelmoune
>
>> Hi,
>>
>> On Mon, Jan 27, 2014 at 2:57 PM, Tollef Fog Heen
>> <tfheen at varnish-software.com> wrote:
>> > Hi all,
>> >
>> > This got triggered by bug #1415 which asks for init scripts to be able
>> > to verify you're not just breaking your cache on a restart.  I can see
>> > the need for such a tool, but I think it should have a bit wider scope.
>> >
>> > Problems:
>> >
>> > - you don't want to restart Varnish when the configuration is
>> >   obviously broken.
>> >
>> > - it should be possible to reload configurations without having to
>> >   fiddle with vcl.load, vcl.use.  Coming up with new names is
>> >   surprisingly annoying.
>> >
>> > - Duplication of logic between RH and Debian init scripts. Varnish
>> >   should probably be able to read a parameter file in some reasonable
>> >   format, which will also make the transition to non-sysvinit inits
>> >   easier.
>> >
>> > Suggestion 1:
>> >
>> > Write something like to apachectl.  It knows how to run a config test,
>> > start and stop the management process.  It makes it easy to run
>> > multiple instances (something that's more important to apache than
>> > us).  It's a bit like a distro-independent init script, but has custom
>> > functions (configtest for instance)
>>
>> I find the idea compelling, but I've had issues with apachectl.
>
> Your problems seem to be "apachectl has bugs", and I wrote "something
> like apachectl", meaning that we'll implement a different set of bugs.
> :-)

As long as the bugs are well documented ;-)

>> I really like the idea of a varnishctl that could be used downstream
>> to build services on top of systemd, upstart etc. But I'd go for a
>> simple pass-through command with simple sub-commands such as
>> start/stop/restart/reload/configtest that would just add sugar such as
>> "configtest on restart" and nothing more.
>
> In the stack, I'd want to have the init scripts call varnishctl, not the
> other way around.

Sorry, this is what I meant. SysVinit, systemd, upstart and the like
that would use varnishctl. By downstream I mean distributions since
they mean you as an upstream of their varnish packages.

>> > Suggestion 2:
>> >
>> > Extend varnishadm to not only be able to talk to varnishd, but also
>> > start and stop the management process, do a config test and so on.
>>
>> Would that mean 3 processes in varnishd ?
>
> No, that wasn't my intention.  What would the third one be?

I don't know ; if varnishd has only two processes as it currently has,
how would you stop the management process ? I understand the feature
to be similar to the current stop/start of the child process through
varnishadm.

Dridi