Right now, MetalLB tries hard to fail static if you delete its configuration, or provide an invalid/unsafe configuration. It does so by ignoring the new configuration (or the deletion of the configuration), and continues serving based on the last known config.
This is theoretically good, because it's a good guard against user error. The problem is k8s gives us no way of VERY LOUDLY telling the cluster operator that something is wrong. The best we can do is flip a Prometheus metric that says "hey we're running on a stale config." In practice, ~nobody does the Prometheus setup to detect this, so it just leads to mass confusion when MetalLB seems to not be working correctly (not allocating IPs to new services, announcing some services but not others...)
I originally thought that using a k8s admission controller would let us eagerly reject invalid configs. Unfortunately that's subject to a race condition where we might accept a config, but then a service changes state in a way that makes the config unsafe before we process the actual reloading. So, we can't make it behave correctly in all cases.
Given that k8s doesn't give us the lever we require, the only sensible thing to do is to remove the fail-static behavior, and always do exactly what the user tells us: if you push a config that makes some service IPs no longer valid, we'll change the service IPs. If you delete the configmap, MetalLB will un-announce all services and just stop doing anything.
It sucks because it means things are a bit less safe, but otoh it'll make MetalLB behave exactly like all other k8s services, in that what you told MetalLB to do is exactly what you'll get.
Right now, MetalLB tries hard to fail static if you delete its configuration, or provide an invalid/unsafe configuration. It does so by ignoring the new configuration (or the deletion of the configuration), and continues serving based on the last known config.
This is theoretically good, because it's a good guard against user error. The problem is k8s gives us no way of VERY LOUDLY telling the cluster operator that something is wrong. The best we can do is flip a Prometheus metric that says "hey we're running on a stale config." In practice, ~nobody does the Prometheus setup to detect this, so it just leads to mass confusion when MetalLB seems to not be working correctly (not allocating IPs to new services, announcing some services but not others...)
I originally thought that using a k8s admission controller would let us eagerly reject invalid configs. Unfortunately that's subject to a race condition where we might accept a config, but then a service changes state in a way that makes the config unsafe before we process the actual reloading. So, we can't make it behave correctly in all cases.
Given that k8s doesn't give us the lever we require, the only sensible thing to do is to remove the fail-static behavior, and always do exactly what the user tells us: if you push a config that makes some service IPs no longer valid, we'll change the service IPs. If you delete the configmap, MetalLB will un-announce all services and just stop doing anything.
It sucks because it means things are a bit less safe, but otoh it'll make MetalLB behave exactly like all other k8s services, in that what you told MetalLB to do is exactly what you'll get.