rfc: a vcl sub context for probe healthy decisions?

[nigoroll]

This rfc is to probe (pun intended) for early feedback on the idea, which is not really cooked yet.

The problem at hand is extended control over the health state of directors: vmod all_healthy adds a way to combine as the health state of a backend that of several (potentially different) backends. Currently, the underlying logic is a conjunction ("and", as implied by all in the vmod name). But there are use cases for additional logic, such as "consider this backend healthy if at least x of these y other backends are healthy". Instead of implementing this logic specifically, I am drawn to the idea of moving the logic into VCL, and I think something along these lines could be implemented by a vmod today:

# STRAWMAN, ask your favorite mansplaining-as-a-service to hallucinate this into an existing feature

sub ah_decide {
  if (ah.n_healthy() / ah.n_backends() > 0.4 && std.healthy(important.backend()) {
    ah.set(healthy);
  } else {
    ah.set(sick);
 }
}

sub vcl_init {
  new ah = all_healthy.director();
  ah.consider(be_a);
  ah.consider(be_b);
  # ...
  ah.set_decider(ah_decide);
}

The above would instruct the vmod to call the vcl sub when the health state is to be determined. The VCL sub could run any code valid in some context (probably VCL_MET_INIT ?). In this example, it would instruct the ah director to be healthy if important.backend() is healthy and at least 40% of all considered backends are, too.

My question is if we want to have a specific VCL_MET_DECIDE context such that the above could be changed into

sub ah_decide {
  if (ah.n_healthy() / ah.n_backends() > 0.4 && std.healthy(important.backend()) {
    return (healthy);
  } else {
    return (sick);
 }
}

or if there are any other good ideas in this area?

edit: The previously proposed name for the VCL context was particularly bad.

[gquintard]

I like that idea. I'd love to see it generalized to probe happiness, and possibly expanded to use a scoring system rather than just a boolean, but I know when I'm getting greedy :-)

I'm fully in favor of VCL_MET_PROBE and not overloading VCL_MET_INIT (which has a very special meaning regarding object creation in the rust world notably)

[nigoroll]

I edited the initial description to suggest the vcl context VCL_MET_DECIDE. The previously suggested name was a particularly bad choice, because it suggested a relation to other ideas around moving backend probe control into VCL.

During a bugwash discussion, @bsdphk asked if this "situation awareness" task could not be better solved with a sub vcl_cron(interval) {}, and I agree. I think we should seriously consider this addition.

[gquintard]

vcl_cron{} would solve a bunch of reload problems, and if you can make the companion vcl_inotify(file){} subroutine to act on file changes...but I'm probably going out of scope here

[nigoroll]

@gquintard that could live in a vmod. FWIW, cron could, too...