Add diagnostics tox env

[sed-i]

Issue

When doing manual tests, I keep using the same lengthy commands over and over.

Solution

Add a diagnostics script to output all the interesting integration-related content.

Context

Came up in during work on canonical/grafana-agent-k8s-operator#160.

Testing Instructions

tox -e diag -- prom/0

Release Notes

Add diagnostics tox env.

[rbarry82]

Rather than leaving line-by-line comments, I'll give a generalized take:

This is nice.

The README note is probably less than clear, and something like "to fetch a summary of alert rules and metrics series present in Prometheus...", as the diagnostics may imply that it actually does some diagnostic work (rather than giving the user information which may help bisect juju data and workload-visible/rendered data) may work, but the actual verbiage is less important.

diagnostics.sh probably doesn't belong in tests/. Rather, some new folder which we don't have a name for. hack/ would be common in "operators", and while that's mostly used for bootstrapping the kubebuilder stuff itself, the paradigm could work here.

[lucabello]

I feel like this type of content could have its own cos-operations repository, or something similar, collecting commands/scripts/recipes we commonly use; I guess it depends on the scope :)

Regardless, I'd use the word diagnostic (or diagnostics) instead of diag since all the other tox environments are full names, not a shorthand

[sed-i]

How about:

pip install cosl
cosl.diag prometheus prom/0

[rbarry82]

How about:

pip install cosl
cosl.diag prometheus prom/0

I mean, couldn't tox just install it as part of the env? And run the command?

I still don't think diag provides enough context. "Hit the API for this particular workload type and print the results" is useful, but it should have a name which reflects what it actually does, because it definitely isn't "diagnosing" anything. Just different kind of juju show-....

Arguably, the best would be to get the Juju team to extend jujuc to behave like kubectl or others, where juju-show-unit -> juju show-unit, juju-show-workload -> juju show-workload ... (which could be further be extended with workload types by different charming teams)

[sed-i]

It's not diagnosing anything yet :)
But I'm not fixed on the name. self-test, check, whatever is fine.

Not sure what you mean about jujuc. Are you talking about juju plugins?