Solution-level Goss checks (complex examples)

[MichaelThamm]

Issue

As part of OPENG-2677, we want to Investigate goss to see how much of the cos doctor capacities we could possibly fulfil with goss. The OB046 - Solution-level Goss checks doc highlights how these self-tests are integral in solution-level Goss checks.

See also: PR#118

Solution

This PR aims to provide:

• Usage Workflow

This architecture is generic (using Goss templates) making it applicable to variations of COS-Lite deployments or (with restructuring) to other deployments.

Context

• This PR assumes that each charm included in COS-Lite has extensive Pebble health checks (self-tests) which can be queried with the /charm/bin/pebble health API.
• External tests are expected to be configured in the goss.yaml file which has access to the host's juju and k8s context (installing these is a prerequisite).
  • Therefore, we can run tests like juju status --relations ... and kubectl describe ....
• In case a Goss check is too long/complex to be a one-liner, a helper .sh script can be placed in the scripts dir and called in the goss.yaml.