feat: COS-Dev mesh pt.1

[MichaelThamm]

Issue

COS-Dev lacked support for a service mesh (Istio) as an alternative networking layer. Users who want mTLS and cross-model relay (CMR) mesh connectivity in COS-Dev had no way to enable it.

Solution

This PR adds initial service mesh support to the COS-Dev Terraform module using Istio (istio-beacon-k8s and istio-ingress-k8s). It is the foundational layer that:

• feat: COS-Dev mesh pt.1 #343

subsequently refactors the API on top of.

What's added

• mesh_enabled variable — a boolean flag (default false) that gates all mesh-related resources. A validation rule prevents mesh_enabled and internal_tls from both being true.
• Istio modules — module "istio-ingress" and module "istio-beacon" are conditionally deployed when mesh_enabled = true.
• Istio ingress integrations — juju_integration.istio_ingress, juju_integration.grafana_istio_ingress, and juju_integration.istio_ingress_route mirror the existing Traefik ingress integrations but route through Istio. They are mutually exclusive with the Traefik integrations (guarded by !var.mesh_enabled on the Traefik side).
• Service mesh integrations — juju_integration.istio_beacon wires the istio-beacon charm's service_mesh endpoint to all seven COS components (Alertmanager, Catalogue, Grafana, Loki, Mimir, OpenTelemetry Collector, Tempo).
• CMR mesh offers — Juju offers for provide_cmr_mesh and require_cmr_mesh endpoints are exposed for all components, enabling cross-model mesh connectivity.

Testing Instructions

Run the Terraform tests:

cd terraform/cos-dev
terraform test

The new mesh_enabled.tftest.hcl test file validates:

• Mesh disabled by default (no Istio modules or integrations deployed).
• Mesh enabled with internal_tls = false (Istio modules and 7 beacon integrations deployed).
• Validation error when both mesh_enabled = true and internal_tls = true.

[adhityaravi]

First pass - we need to add the istio-k8s charm into the deployment which seems to be missing at the moment. It probably needs to be in its own model istio-system

[MichaelThamm]

@adhityaravi I would argue that this does not belong in our product, rather deployed separately. Similar to what we do with external-ca model in our itests for external-tls:

• https://github.com/canonical/observability-stack/blob/main/tests/integration/cos_dev/tls_external/track-dev.tf#L29-L41

However, this is up for debate because the CC008 spec does impose anything on us. I guess the question is: could COS operate without istio-k8s in the COS model? Since the "best-practice" is to have this in a separate model, then we want this to be integrated with COS via juju_offers and accepting integrations via inputs. We need to think carefully about this as this will start to become more and more of an API burdon: previously we only had to support the external__offer_url. We should try to see if implementing:

For optional external integrations (e.g. COS), the product modules should expose the variables to allow the external integrations with user-defined endpoint/offers

make sense. Ref link