-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Global Reconciliation Loop #1364
Comments
Apologies that this is pretty light on expected behavior and architecture. My golang knowledge is still a bit rudimentary, and I wouldn't presume to suggest where the most central changes should occur. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is related to #958 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I've been experiencing the situation where transient failures occur in https://github.com/coreos/flannel/blob/master/backend/vxlan/vxlan_network.go#L145 especially under heavy memory contention. The current code structure in vxlan_network does not include a facility for retries, which results in the newly observed subnet never being properly added to netlink, which gives rise to #958
After discussions in the 10/29/2020 community meeting, Rajat proposed that rather than add retries to the code within vxlan_network.go that we would want to move to an architecture with a global reconciliation loop, to be run on some configurable interval, that would compare the etcd or k8s contents with the current set of iptables rules and make any required changes. This would help in reducing or eliminating all persistent error conditions, not just the one underlying 958.
The text was updated successfully, but these errors were encountered: