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
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?
The text was updated successfully, but these errors were encountered:
Added some comments to the PR. Thank you for taking this on! The place to make this change is not quite right, but you are correct that it's a fairly straightforward change, and I'm happy to guide you through it.
(Oops, commented via work account rather than personal one - too lazy to switch over, but it's me, danderson :) )
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?
The text was updated successfully, but these errors were encountered: