Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration isn't reapplied after service deletion #413

Closed
alexlovelltroy opened this issue Mar 5, 2019 · 1 comment
Closed

Configuration isn't reapplied after service deletion #413

alexlovelltroy opened this issue Mar 5, 2019 · 1 comment

Comments

@alexlovelltroy
Copy link
Contributor

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?

@dave-tock
Copy link

dave-tock commented Mar 6, 2019

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 :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants