Right now if a charm wants to integration test observability relations with COS, they have to figure out:
- which concierge spec to use to prepare the substrate (microk8s version, juju version...)
- how to configure the terraform plan
- update their integration testing workflows to do all of that
To help other teams/repos test against COS, reducing boilerplate, we could improve the terraform.yml and _integration.yml recipes we have on this repo to be reusable and public.
What could it look like:
# myrepo/.github/workflows/integration_tests.yaml
jobs:
deploy-cos:
name: Deploy COS
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: github.com/canonical/observability-stack/deploy-cos@v1
with:
cos-model: cos
controller: cos-ctrl
flavor: pro-max-ultra # or whatever
integration-tests:
# run integration tests; now there is a microk8s controller and a cos model in it
This will apply a tf module (with a specific 'flavor') as per leon's table below.
This implies extending the cos-pro TF module so we can use it to deploy any one of the variants we intend to support. (see this for a draft of what it might look like)
Unless it's too much work or ugliness in which case we might consider having separate TF modules but let's try to avoid it.
Right now if a charm wants to integration test observability relations with COS, they have to figure out:
To help other teams/repos test against COS, reducing boilerplate, we could improve the terraform.yml and _integration.yml recipes we have on this repo to be reusable and public.
What could it look like:
This will apply a tf module (with a specific 'flavor') as per leon's table below.
This implies extending the cos-pro TF module so we can use it to deploy any one of the variants we intend to support. (see this for a draft of what it might look like)
Unless it's too much work or ugliness in which case we might consider having separate TF modules but let's try to avoid it.