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 health would make
sense in the same way as the ban() cli command makes sense: in some cases,
controlling such functionality in-band avoids additional complications.
> Admin=sick means sick, no matter what the director implementation thinks.
>
> Admin=healthy means healthy, --//--
>
> Admin=??? means "Implementation decides if sick or healthy."
>
> Best proposal for "???" seems to be "auto", even though it is not
> entirely on point.
Ack. But I'd still like to see "auto" be a write-only health state, resulting in
healthy or whatever the implementation returns for ->list().
> In the new API, there is a director method called ->list() which
> gets called during CLI command 'backend.list' so that UX can reflect
> what the implementation actually know as best as possible.
It seems to make a lot of sense to replace "probe" and "dependent" from my
proposal with an implementation specific value. So ->list() would fill out both
the fields replacing the current "Admin" and "Probe" fields.
>2) Headers in backend.list
Admin and Check ?
>3) What does H1 backend without probe do for ->list()
return Admin=Healthy Check=-
>4) What does H1 backend with probe do for ->list()
return Admin=Healthy Check=
>5) What do vmod_directors do for ->list()
sensible default:
return Admin=dependent Check=n/m number of healthy/total backends in the
director
Also I'd like to push again for the "disabled" admin state: Yes, this could be
implemented with another director layer, but I think the additional flag belongs
to the fundamental director because the proposed functionality is fundamental
and can be found in all the loadbalancer appliances I've encountered so far.
> I'm pondering a "VCL_BACKEND std.resolve_backend(VCL_BACKEND)" to
> avoid what seems to me to be a lot of complexity in shard to do
> the same?
The complexity in shard is not for resolve=NOW, but for resolve=LAZY: We need to
keep track of all the load balancing parameters without actually making the
decision. At this point, they are stored in a PRIV_TASK which cannot cross the
client/backend boundary, so we need to special case based on which side we're
running on.
I think that replacing resolve=NOW with std.resolve_backend() would make the
situation even more confusing for users as resolve=LAZY has limitations and
resolve=NOW doesn't.
If anything, with the current code, std.resolve_backend() would make sense for
the the directors EXCEPT for shard.
If we wanted to generalize more, I think we'd need something like a PRIV_REQ:
- can be created on the client side
- ownership transferred to the backend side or fini'd if no backend
request
Nils
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
