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:
model: cos
controller: cos-ctrl # the controller we'll deploy our cos model to. We'll pass this to the juju provider.
module: cos # cos|cos-lite|cos-dev
ref: main # git branch or ref, e.g. 'track/2', or 'main'
integration-tests:
# run integration tests; now there is a microk8s controller and a cos model in it
Then we add a new 'cos-dev' TF module which deploys:
- all HA charms with role-all, scale 1
- seaweedfs instead of s3-integrator
If user selects 'cos', we deploy standard cos, if user sets 'cos-lite', same.
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:
Then we add a new 'cos-dev' TF module which deploys:
If user selects 'cos', we deploy standard cos, if user sets 'cos-lite', same.