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 _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev