Don't hardcode MetalLB IP range in the microk8s preset

[dwilding]

The microk8s preset hardcodes metallb:10.64.140.43-10.64.140.49 in its addon list. This range is for Canonical's internal network. On GitHub Actions runners, MetalLB sometimes never allocates a usable LoadBalancer IP from this range within a reasonable wait window. The result is that charms requiring a LoadBalancer (e.g., Traefik in COS Lite) get stuck in blocked state indefinitely.

For a sample failure, see https://github.com/canonical/operator/actions/runs/32157684730/job/95778751483.

The Observability team worked around this by not using Concierge at all. They compute the MetalLB IP dynamically from the runner's own primary IP.

In Ops, I'm planning to avoid the issue by switching to the k8s preset - which we already use in the K8s charm tutorial.

But I think the issue is still worth fixing in Concierge's microk8s provider. Here's what my agent recommends:

1. Auto-detect the MetalLB IP when no range is explicitly configured. Instead of hardcoding 10.64.140.43-10.64.140.49, detect the host's primary IP using ip -4 -j route get 2.2.2.2 | jq -r '.[] | .prefsrc' and use that single IP as the MetalLB range. This is the same approach the Observability team uses in their CI. It works universally because the IP is on the runner's own network interface, so L2 ARP always succeeds. Users who explicitly set a MetalLB range in their config are unaffected.

2. Validate the IPAddressPool after enabling. The microk8s metallb addon creates an IPAddressPool CR and an L2Advertisement. After enabling, check that the IPAddressPool exists and contains the expected addresses. If it doesn't (MetalLB silently discards invalid configs), patch the IPAddressPool directly with the detected IP. This catches the silent-failure cases that make the current bug hard to diagnose.

[tonyandrewmeyer]

A comment from the 26.10 charming survey overlaps with this:

Provisioning add-ons like metallb require hardcoding an IP range directly in concierge.yaml (metallb:10.64.140.43-10.64.140.49). It could be useful to have a documented "auto-assign a free range" mode to remove environment-specific config.

Perhaps we can solve both here?

[tonyandrewmeyer]

I had a go at (1) in #266, and it has a downside worth recording before anyone else picks this up.

Giving MetalLB the host's own address means the cluster gets a claim on that address for whatever port a LoadBalancer Service asks for. On microk8s 1.35 in a clean 24.04 VM, with the pool set to the node's own address and a plain HTTP server running on the host on :8080:

request	answered by
from off-host, to <node IP>:8080	the Service
from the node, to its own IP	the Service
from the node, to 127.0.0.1:8080	the host process

The host process stays listening on 0.0.0.0:8080 throughout, nothing errors, and loopback keeps working, so it doesn't present as a port conflict from either end - the host just stops getting traffic on its own address. Repeating the same test with the pool pinned to a fixed range instead, the host process answers on <node IP>:8080 as normal.

On a runner, the ports a charm's Services want (80, 443, 8080) are the ports something on the host is plausibly already serving, so I don't think this can be the default.

What's in #266: the range becomes configurable through providers.microk8s.metallb-ip-range, auto opts into the host's address, and a bare metallb keeps the example range MicroK8s itself suggests. That makes the range settable, which is most of what this asks for, but it doesn't change the default, so the out-of-the-box behaviour you hit on GitHub Actions is unchanged - you'd set the option (to auto or to a range that suits the runner).

Leaving this open, because (2) is untouched and I suspect it's the more useful half: if MetalLB is silently discarding the config, checking the IPAddressPool afterwards would turn a charm stuck in blocked into an error message that says what happened.