Mailing List Archive

Hi Batanun,

I'm curious, if it's completely deactivated what's the benefit of having it
in the vcl?

To answer your question: cheat! Add this somewhere in your vcl:

sub vcl_recv {
# the if statement will never work, but the backend is referenced, so
the compiler won't bother you
if (false) {
set req.backend_hint = you_deactivated_backend;
}
}

You could also start varnish with `-p vcc_feature=-err_unref` but I don't
recommend it as it'll affect all the unreferenced symbols, even the ones
you may care about.

Hope that helps

--
Guillaume Quintard


On Fri, Apr 14, 2023 at 4:53?AM Batanun B <batanun@hotmail.com> wrote:

> Hi,
>
> We are currently working on a new feature that won't go live for several
> months still. This new feature has it's own backend in Varnish. Most of our
> VCL code is identical for all environments, and this code refers to the new
> backend, so it needs to be defined otherwise Varnish won't start. But in
> production we don't want to show anything of this feature. And we would
> like to have this backend completely disabled or inactivated in Varnish.
> Can we do that using VCL? Like forcing the health to be sick, or something
> similar. We would prefer to keep this inside the backend declaration if
> possible, and we would also prefer somethink not too "hackish" (like
> pointing it to a dead IP).
>
> Does Varnish has any recommended approach for this? I know there is a cli
> command to set the health, but as I said we would really prefer doing this
> using VCL only.
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>

Hi Guillaume,

> I'm curious, if it's completely deactivated what's the benefit of having it in the vcl?

It is only intended to be deactivated in production (until we go live). Our test and staging environments have the backend active.

> if (false) {
> ??set req.backend_hint = you_deactivated_backend;
> }

Thanks, I will test this.
My current prod-specific setup for this backend looks like this:

backend theBackend {
.host = "localhost";
.port = "9999";
.probe = {
.interval = 1h;
}
}

This seems to be working when testing it locally. It also solves the problem of having to assign some arbitrary ip or hostname (the actual backend host for this service hasn't been created in production yet, since we are several months away from go live), which actually was our main problem. What do you think about this approach instead? Preferably this would be a built in feature in Varnish, with a setting "disabled = true" or similar in the backend definition, and then it would not require any host or ip to be configured.

Thank, I think I get it now. How about:

backend theBackend none;

Here's the relevant documentation:
https://varnish-cache.org/docs/trunk/users-guide/vcl-backends.html#the-none-backend
It was added in 6.4.

Hope that helps.

--
Guillaume Quintard


On Wed, Apr 19, 2023 at 1:36?AM Batanun B <batanun@hotmail.com> wrote:

> Hi Guillaume,
>
> > I'm curious, if it's completely deactivated what's the benefit of having
> it in the vcl?
>
> It is only intended to be deactivated in production (until we go live).
> Our test and staging environments have the backend active.
>
> > if (false) {
> > set req.backend_hint = you_deactivated_backend;
> > }
>
> Thanks, I will test this.
> My current prod-specific setup for this backend looks like this:
>
> backend theBackend {
> .host = "localhost";
> .port = "9999";
> .probe = {
> .interval = 1h;
> }
> }
>
> This seems to be working when testing it locally. It also solves the
> problem of having to assign some arbitrary ip or hostname (the actual
> backend host for this service hasn't been created in production yet, since
> we are several months away from go live), which actually was our main
> problem. What do you think about this approach instead? Preferably this
> would be a built in feature in Varnish, with a setting "disabled = true" or
> similar in the backend definition, and then it would not require any host
> or ip to be configured.
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>

> backend theBackend none;
> Here's the relevant documentation: https://varnish-cache.org/docs/trunk/users-guide/vcl-backends.html#the-none-backend
> It was added in 6.4.

Look like exactly what we need! Sadly we are "stuck" on 6.0 until the next LTS version comes. So I think that until then I will use our poor man version of the "none" backend, ie pointing to localhost with an port number that won't give a response.

On Wed, Apr 19, 2023 at 3:45?PM Batanun B <batanun@hotmail.com> wrote:
>
> > backend theBackend none;
> > Here's the relevant documentation: https://varnish-cache.org/docs/trunk/users-guide/vcl-backends.html#the-none-backend
> > It was added in 6.4.
>
> Look like exactly what we need! Sadly we are "stuck" on 6.0 until the next LTS version comes. So I think that until then I will use our poor man version of the "none" backend, ie pointing to localhost with an port number that won't give a response.

It was back-ported to 6.0, which is not an LTS branch limited to bug fixes ;)

https://varnish-cache.org/docs/6.0/users-guide/vcl-backends.html

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

> It was back-ported to 6.0, which is not an LTS branch limited to bug fixes ;)
>
> https://varnish-cache.org/docs/6.0/users-guide/vcl-backends.html

Thanks! Wow, I can't believe that I could miss that. I thought I read that specific page, as well as searched on Google, but I guess I was too focused on looking for terms like "disabled" or "inactivated".