In my cluster, we are adding and removing layer-2 address-pools fairly frequently. Sometimes we accidentally update the configuration to remove an address pool before the last service using the pool has released it. Since MetalLB doesn't re-read the ConfigMap after the service is deleted, we need to push the unchanged ConfigMap again to trigger a reload.
After reading the code, I think the right thing to do is trigger a reload of the ConfigMap with SetConfig() within the main controller after the deletion has happened. I'm thinking around line 98
https://github.com/google/metallb/blob/e5dd238516dbc6ed39c08965ea7594a20da374c1/controller/main.go#L98
Before I tackle this and offer a PR, can someone more familiar with this codebase comment on the approach? Is there a better place for this behavior? Is there a better function to call?
In my cluster, we are adding and removing layer-2 address-pools fairly frequently. Sometimes we accidentally update the configuration to remove an address pool before the last service using the pool has released it. Since MetalLB doesn't re-read the ConfigMap after the service is deleted, we need to push the unchanged ConfigMap again to trigger a reload.
After reading the code, I think the right thing to do is trigger a reload of the ConfigMap with SetConfig() within the main controller after the deletion has happened. I'm thinking around line 98
https://github.com/google/metallb/blob/e5dd238516dbc6ed39c08965ea7594a20da374c1/controller/main.go#L98
Before I tackle this and offer a PR, can someone more familiar with this codebase comment on the approach? Is there a better place for this behavior? Is there a better function to call?