changing ipaddress pool needs a good way to propagate into traefik service

[nishant-dash]

Enhancement Proposal

if you have a setup with metallb and ipranges set in the metallb charm, an ipaddresspool object is created in k8s from which the loadbalancer for traefik gets an ip
If you change this ipaddresspool (metallb ipranges charm config), there does not seem to a be a good/smooth/juju way to get an updated ip for traefik for example.
I presume this generally applies to all relevant juju k8s charms

Metallb docs suggest

1. restarting the MetalLB’s controller pod
2. deleting and re-creating the service

source: https://metallb.universe.tf/configuration/_advanced_ipaddresspool_configuration/#changing-the-ip-of-a-service

TO reproduce this behaviour:

1. deploy k8s
2. deploy metallb with ipranges config set to any local ip
3. deploy cos-lite bundle
4. change the metallb ipranges config

[PietroPasotti]

I thought juju would keep an eye on the backing service and pop a config-changed if that happens to get modified?
But indeed we should check this

[PietroPasotti]

@nishant-dash would adding an action to traefik to refresh the IP help mitigate this issue?
The charm has no way to 'notice' if the IP has changed.
Doing it on a schedule (e.g. custom pebble notice, cronjob, resurrect) is tricky because we'd need to do that very frequently to avoid "too much" data loss.
We could combine the approaches.

[nishant-dash]

@PietroPasotti I think having an action to get it to request a new ip is ok, but eventually if there was a better way to handle this, maybe something the metallb charm could help with, having the charm automatically refresh its ip would be ideal

[gboutry]

Just to chime in since my issue was closed as duplicate #401

Modifying the k8s svc created by Juju makes Juju run config-changed event on the charm when the IP address has changed. I know it has other drawbacks, but it makes the charm aware of IP change in K8S.