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

[Nils Goroll]

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=<unchanged>

>    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