-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
agent: Handle correctly state when CEP is present in multiple CESs #24838
Conversation
a71b662
to
dd36ea4
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.
agent: Fix a when CEP is present in multiple CESs, e.g. when it's transferred between CESs.
What's the user-visible impact of this bug?
CEP missing from the ipcache. Current state:
The end state is that CEP is missing from the ipcache. |
dd36ea4
to
b13e1c9
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.
lgtm
@alan-kut Thanks for the contribution! Is there any issues open for this bug? |
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.
The release note in the PR description needs to describe the user-visible impact (e.g., pods can't start, packets are dropped due to policy denies, etc.) such that it is useful to users when displayed in our release notes.
b13e1c9
to
67049e6
Compare
I updated the code with the tommyp1ckles suggestions. I updated the release notes - the user visible impact is that some traffic may be incorrectly denied or allowed because eBPF maps will not be set properly because ipcache inside agent is misconfigured on some cases when CEP changes CES. I'm not aware of any issue created for this problem. |
67049e6
to
28969d9
Compare
@alan-kut The changes look good to me. I am curious, what are the circumstances that a CEP can exist in two CES? |
One example is when CEP is moved to a different CES (especially easy to trigger with identity batching when identity changes): add CEP to 2nd CES and then remove CEP from the 1st CES. |
So it's not theoretical bug - I can reproduce it - but in general - it's valid, temporarily state that CEP exists in multiple CESs. Even if we remove all current occurrences it may happen in the future, as intended or due to bug. I think long term we need proper reconciliation logic but for now this should work. Are we good to merge? |
There are condition possible in which CEP changes CES. This leads to CEP being present in multiple CESs for some time. In such cases the standard logic may not work as it always expect to have a single CEP representation. This commit changes to logic to handle multiple CEPs properly. Signed-off-by: Alan Kutniewski <kutniewski@google.com>
28969d9
to
1b05a80
Compare
My concern was addressed. I'll let others more familiar with that logic review the changes.
We had some discussion during the community meeting today (notes), for now we will apply the regular policy for this PR. We'll follow up on clarifying the backporting policy for beta features going forward. |
Marking for backport to v1.12, v1.13 unless anyone has concerns about the risk for backporting these changes to older branches. |
Hi @alan-kut – did you assess the applicability of this issue against v1.11 in addition to v1.12? We would want to backport it to that version too unless you have reason to believe it doesn't apply. |
Hi @ferozsalam - it applies and the backport is not complex. I backported it manually in my internal repo. |
Backports for v1.12 and v1.13 are done. |
There are condition possible in which CEP changes CES. This leads to CEP being present in multiple CESs for some time. In such cases the standard logic may not work as it always expect to have a single CEP representation.
This commit changes to logic to handle multiple CEPs properly.