Re: backend/director admin states / std.resolve_backend? / PRIV_REQ?

On 09/05/18 11:34, Nils Goroll wrote: > ban() cli VCL that is ___ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: backend/director admin states / std.resolve_backend? / PRIV_REQ?

I guess this thread still lacks my response to phks reply: On 03/05/18 11:20, Poul-Henning Kamp wrote: > Admin health is owned by the CLI and director implementations do not > get to meddle with it. (But they do get to see it) I understand the point, but allowing vmods to change the admin

Re: backend/director admin states

In message , Dridi Boukelmoune writes: >All we need is TheNewGuy(tm) to dump this on their desk :p Indeed, they grow up so fast, don't they ? :-) Anyway, I would like to get back to the actual underlying

Re: backend/director admin states

On Fri, May 4, 2018 at 9:42 AM, Poul-Henning Kamp wrote: > > The reason we have include/tbl/cli_cmds.h in the first place was > that I wanted some kind of "schema-light" for UX use, but that > didn't happen. Yes, that experiment failed, but I somehow succeeded in

Re: backend/director admin states

In message , Dridi Boukelmoune writes: >I experimented with this a while back and tried this: > >[...] > >I never completed the last experiment because the time I allocated >eventually ran out and I lost motivation to

Re: backend/director admin states

>>Maybe we should do that the other way around? Have all CLI commands >>reply with a JSON data structure, and CLI consumers like varnishadm, >>varnishtest or varnishd -d be able to output it in plain text (with >>this code centralized in libvarnish and exposed in libvarnishapi). > > I thought

Re: backend/director admin states

In message

Re: backend/director admin states

On Thu, May 3, 2018 at 1:04 PM, Poul-Henning Kamp wrote: > > In message > > , Guillaume Quintard writes: > >>All commands should have a JSON option, I reckon. > > Somebody should write more code

Re: backend/director admin states

Yp, that's on my plate. Which is rather large... -- Guillaume Quintard On Thu, May 3, 2018, 13:04 Poul-Henning Kamp wrote: > > In message c5q-zxfqjcu0k...@mail.gmail.com> > , Guillaume Quintard writes: > > >All commands

Re: backend/director admin states

In message , Guillaume Quintard writes: >All commands should have a JSON option, I reckon. Somebody should write more code for it then, I reckon :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20

Re: backend/director admin states

All commands should have a JSON option, I reckon. -- Guillaume Quintard On Thu, May 3, 2018, 12:52 Poul-Henning Kamp wrote: > > In message <1401d370-56dd-6006-2b3d-21771650f...@uplex.de>, Geoff Simmons > write > s: > > >>> Illustrated example: varnishadm

Re: backend/director admin states

In message <1401d370-56dd-6006-2b3d-21771650f...@uplex.de>, Geoff Simmons write s: >>> Illustrated example: varnishadm backend.list output We should also think about varnishadm backend.list -j ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP

Re: backend/director admin states

In message

Re: backend/director admin states

> Best proposal for "???" seems to be "auto", even though it is not > entirely on point. > > The implementation can control its view of the health two ways > > A) Call VRT_SetHealth() and set it on the director. > (useful for probes as we know them) > > B) Provide a ->healthy() method

Re: backend/director admin states

OK, let me try to explain my mental model of this: Admin health is owned by the CLI and director implementations do not get to meddle with it. (But they do get to see it) Admin=sick means sick, no matter what the director implementation thinks. Admin=healthy means healthy, --//--

Re: backend/director admin states

On 05/03/2018 10:49 AM, Dridi Boukelmoune wrote: >> Illustrated example: varnishadm backend.list output >> >> Backend name Admin Probe Last change >> boot.b1 probe 0/8 badWed, 02 May 2018 13:22:10 >> GMT >> boot.b2

Re: backend/director admin states

Hi, On 02/05/18 17:07, Guillaume Quintard wrote: > I think I could live with "auto" meaning "dependent/probe" depending on the > type > of object. Me too, but I also think that for varnishadm backend.list output, displaying the actual facts is significantly more helpful. > Not sure the

Re: backend/director admin states

I think I could live with "auto" meaning "dependent/probe" depending on the type of object. Not sure the disabled case is super useful. If I get what you say, the only thing differing from setting it to sick is that we keep using the open connections, instead of finishing in-flight requests. Is