-
Notifications
You must be signed in to change notification settings - Fork 591
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
feat: store and push last valid config #4205
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #4205 +/- ##
=======================================
- Coverage 62.5% 62.5% -0.1%
=======================================
Files 154 154
Lines 17114 17123 +9
=======================================
+ Hits 10700 10704 +4
- Misses 5729 5732 +3
- Partials 685 687 +2
☔ View full report in Codecov by Sentry. |
b5ea699
to
6a548dd
Compare
c902031
to
3f4c1f3
Compare
3f4c1f3
to
8a60acd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should indeed not resend configuration if a gateway already has the configuration the fallback wants to send, correct?
It looks like that's the case since PerformUpdate computes a hash from the config provided (so it does compute different hashes for the new, broken config and the fallback) rather than earlier, so we don't get a situation where we think the comparison still finds a change when sending the fallback.
We would want to avoid broken configuration resulting in a situation where we effectively enable reverse sync and always send configuration, since updates are expensive. It looks like we do indeed avoid that without any new logic to avoid it for the fallback, however, and the rest looks fine, so approving with an optional changelog addition.
8a60acd
to
8d1ca8f
Compare
@rainest @pmalek @mheap I've updated the CHANGELOG as Travis suggested and I think we can merge this one. My intention is to create a new issue for fetching the latest good configuration from the Proxy and tackle it in a different PR (we need to add a go-kong update as well), along with the hash thingy (fundamental when implementing the fetch from proxy feature). Are you ok with this approach? |
Signed-off-by: Mattia Lavacca <lavacca.mattia@gmail.com>
8d1ca8f
to
70b70d0
Compare
70b70d0
to
0115d93
Compare
Signed-off-by: Mattia Lavacca <lavacca.mattia@gmail.com>
0115d93
to
07ea022
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is (still) good to go but IDK if ya'll want to continue anything in the open comment threads, so approving again but leaving it up to @mlavacca to close them/merge.
The thread's discussion will be addressed in a separated PR. I added some unit testing to address @czeslavo comment. Waiting for his approval. |
@mflendrich Flagged some potential issues with fetching config from a running DP if running in DB-backed and using both KIC and deck. Agree to merge this PR as-is, but we should consider limiting "fetch from DP" mode to DB-less only in a future PR |
What this PR does / why we need it:
Which issue this PR fixes:
Fixes #4048
Special notes for your reviewer:
E2E run with these changes: https://github.com/Kong/kubernetes-ingress-controller/actions/runs/5336108716/jobs/9670625415
PR Readiness Checklist:
Complete these before marking the PR as
ready to review
:CHANGELOG.md
release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR