Closed The-9880 closed 4 months ago
Looking at the other PR (https://github.com/grafana/synthetic-monitoring-agent/pull/675), I'm thinking that whether or not a probe is allowed to run scripts is something that should be set the API level (because the probe is created and available before it connects to the API). The API should tell the probe "you are supposed to run scripts" and the probe can validate that the feature flag is set (or that it's able to run k6, because the binary is available, or it's been provided with a URL for the runner).
So I think the proto message should be extended to include that info, and the API should be extended so that a probe is eligible for running k6 checks or not.
Looking at the other PR (#675), I'm thinking that whether or not a probe is allowed to run scripts is something that should be set the API level (because the probe is created and available before it connects to the API). The API should tell the probe "you are supposed to run scripts" and the probe can validate that the feature flag is set (or that it's able to run k6, because the binary is available, or it's been provided with a URL for the runner).
So I think the proto message should be extended to include that info, and the API should be extended so that a probe is eligible for running k6 checks or not.
I think that having the API determine if the probe should run the check or not will add some UI overhead and also some friction in toggling this for a probe.
Here are a few of my thoughts:
ProbeInfo
) upon registration is more flexible - otherwise, I would have to create a 'new probe' on the API and change my token to toggle scripted checks execution.I figure it makes sense regardless to do the same set of validations on a probe if someone enables Feature.K6
on it, but maybe I'm missing something with that.
Edit: though I think if we want some probes to have K6 enabled (i.e. for MultiHTTP checks) but not perform more complex scripted checks, we could add a separate flag for this enablement.
EDIT (4/15/24): we're going with an API-driven implementation - resolving prior threads and updating PR.
First in line for restricting scripted/browser checks to enabled probes.
We add a
Capabilities
structure which contains flags for different 'features' we might enable on probes. The Agent can have a method which takes this structure in and validates its setup against this config.The first field in here is
DisableScriptedChecks
which is set if the probe is disallowed from receiving scripted checks to execute.