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
A few cleanups for per-cluster CT/SNAT maps #25712
A few cleanups for per-cluster CT/SNAT maps #25712
Conversation
/test |
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. Just a minor nit inline
Let me ask for your review as a CLI team @squeed as you were originally assigned 🙏 |
1. Don't create per-cluster inner maps in the delete functions 2. Fix map access with wrong address family in DeleteClusterCTMaps 3. Clarify deliberately ignored deleteClusterNATMap error in the PerClusterNATMap.cleanup(). 4. Fix various bugs that we miss the last element in per-cluster CT/SNAT outer maps when we iterate over them. Update test cases to use last element to prevent such bugs in the future. 5. Don't Unpin() on cleanup logic of GetAllClusterCTMaps(). 6. Don't return error when deleteClusterXXMap failed with no exist. 7. Add ClusterID logfields. 8. Log an error on cleanup failure of per-cluster NAT maps. Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
Currently, we use hard-coded outer map name suffix (e.g. "tcp4" for CT maps, "v4_external" for NAT maps, etc) and inner map name suffix (e.g. "1") in some places including test code. That means we are assuming such naming scheme in multiple places and it is easy to make naming mistakes. To prevent the issue, remove all hard-coded outer map suffix and replace them with variables. Also, remove all hard-coded inner map suffix and use function to generate inner map names. This commit also removes the hard-coded outer and inner map names of NAT map. This makes easy to change the map names in the tests. Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
9da6ddd
to
02b94e7
Compare
/test |
k8s-1.26-kernel-net-next: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.26-kernel-net-next/273/ Suite-k8s-1.26.K8sUpdates and K8sDatapathBandwidthTest failures are due to the Docker rate limit |
K8sDatapathBGPTests (https://jenkins.cilium.io/job/Cilium-PR-K8s-1.26-kernel-net-next/273/testReport/Suite-k8s-1/26/K8sDatapathBGPTests_Tests_LoadBalancer_Connectivity_to_endpoint_via_LB/) is not clear. Let me retry to see consistency. |
/test-1.26-net-next |
ConformanceIngress: New flake since nothing on this PR should affect to the L7. Filed an issue: #25776 |
I'm pretty sure the flake of the
PodIP is assigned regardless of the Pod state (even if it is ImagePullBackOff, IP address is assigned). So, this condition is met even if FRR itself is not ready. This should be fixed in this PR (#25777). |
All green. Ready to merge. |
Please see the commit messages for more details.