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
endpoint: trigger k8s sync controller on identity update #16381
Conversation
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.
Thanks a ton for taking care of this! Looks good overall. I have some minor nits (none of which need to be blocking)
pkg/controller/manager.go
Outdated
@@ -135,7 +136,7 @@ func (m *Manager) removeController(ctrl *Controller) { | |||
ctrl.getLogger().Debug("Removed controller") | |||
} | |||
|
|||
func (m *Manager) lookup(name string) *Controller { | |||
func (m *Manager) Lookup(name string) *Controller { |
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.
No action required, just a thought:
One thing that I just noticed is that this export here is the first export that gives access to a Controller
struct outside of the package. All other methods of the Manager
do not allow direct access to the Controller
. While it seems safe (i.e. it seems that m.mutex
is not protecting it), I wonder if it might be cleaner and more future-proof to expose a TriggerController(name string)
method instead (similar to TerminationChannel
), instead of allowing a a direct lookup.
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.
Yeah, makes sense, that's where (e *Endpoint) TriggerController(name string)
should actually live 👍
Signed-off-by: Gilberto Bertin <gilberto@isovalent.com>
a3e881a
to
26d3fca
Compare
test-me-please |
@jibi can you add the GH issue ID this fixes? |
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.
LGTM. I have one suggestion below, but LMK what you think on it.
When an endpoint's identity is updated, Cilium does not sync immediately the new state with k8s, but rather waits up to 10 seconds for the sync-to-k8s-ciliumendpoint controller to run, meaning that the the new identity can remain unannounced for up to 10 seconds. This commit fixes this by explicitly triggering the k8s sync controller whenever an endpoint's identity is updated. Fixes: #15097 Suggested-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Gilberto Bertin <gilberto@isovalent.com>
26d3fca
to
35b2ed8
Compare
My bad, I thought GH would look for that also in commit messages 🤦♂️ |
test-me-please |
retest-5.4 |
Added for backporting to 1.10, otherwise we'll continue having these flakes in 1.10 automated jobs ad vitam æternam. |
When an endpoint's identity is updated, Cilium does not sync immediately
the new state with k8s, but rather waits up to 10 seconds for the
sync-to-k8s-ciliumendpoint controller to run, meaning that the the new
identity can remain unannounced for up to 10 seconds.
This commit fixes this by explicitly triggering the k8s sync controller
whenever an endpoint's identity is updated.
Fixes #15097