adr: juju-doctor #260
adr: juju-doctor #260
Conversation
There was a problem hiding this comment.
Good start @MichaelThamm!
- I think at this point we should reduce the scope of the ADR to "Charm probes"
- I think the requirements listed are actually the decision itself.
There was a problem hiding this comment.
Thanks for the draft :) Leaving a few comments
I agree with both points Leon made!
Other than running juju-doctor --probe ... --probe ... --model ... etc, we might allow defining a simple yaml config file that defines the CLI arguments; the one-liner could otherwise become too long, and hard to repeat consistently if executed on different machines.
We could even allow said config files to live somewhere remotely (e.g. on a repository) and fetch it, e.g. with juju-doctor --config=https://...)
Just a few ideas :)
| `juju-doctor` could work in a similar way by generating/receiving a standardized dump (status.yaml, bundle.yaml, show-unit.yaml) and validating this deployment. The deployments variations (theoretically infinite) that `juju-doctor` needs to validate cannot be maintained solely by the Observability team. This introduces the decentralized probes (a unit-like test) architecture, where the tool can pull probes from remotes which are maintained by the stakeholders of the charm/deployment/probe | ||
|
|
||
| ## Requirements | ||
| 1. Probes are runnable without `juju-doctor` (piping from stdin) |
There was a problem hiding this comment.
I'm not clear on the value of this. What advantage does that provide vs running juju-doctor and pointing to one probe?
Minor thing: note that this is not enforceable on probes written by others, it'd be a convention that others might not follow.
It also prevents us from "sandboxing" the execution in any way, and the responsibility would fall on each individual probe.
There was a problem hiding this comment.
Edge cases:
- Multiple juju-status.yaml (e.g. CMRs) as input to probe/doctor
- CMRs to k8s models need to go through an ingress
- With
juju status --format json we can find CMR info inapplication-endpoints` key:
- With
"application-endpoints": {
"graf": {
...
},
| The user of `juju-doctor` is responsible for defining the remote probes required for the current validation and could define: | ||
| 1. Multiple probe URLs (`--probe probe-1.py --probe probe-2.py`) | ||
| 2. A directory of probes (run all inside) |
There was a problem hiding this comment.
I would add (3), multiple charms for which to fetch probes (--charm grafana-k8s --charm loki-k8s), where juju-doctor could do:
- from charm name, get the repo
- from repo, get the probes (under
/probes)
There was a problem hiding this comment.
Until we get to option 5 there's no hope to agree on any of this
Please review