Skip to content
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

v1.9 backports 2021-03-10 #15298

Merged
merged 4 commits into from
Mar 10, 2021
Merged

Conversation

pchaigno
Copy link
Member

@pchaigno pchaigno commented Mar 10, 2021

Skipped:

Once this PR is merged, you can update the PR labels via:

$ for pr in 15175 15179; do contrib/backporting/set-labels.py $pr done 1.9; done

pchaigno and others added 4 commits March 10, 2021 10:46
[ upstream commit 2a62b83 ]

Using the NatMap interface was causing issues when trying to check if
the natMap attribute is nil. We don't need the NatMap interface and can
simply use *nat.Map directly.

Suggested-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Paul Chaignon <paul@cilium.io>
[ upstream commit 37ab40e ]

Initialize the kube-proxy replacement options earlier in the agent
startup, to ensure all options have reach their final state (based on
kernel probes and option conflict) when we initialize the BPF map
information (e.g., create or not NAT maps based on whether BPF NodePort
is enabled).

Signed-off-by: Paul Chaignon <paul@cilium.io>
[ upstream commit 602e5ce ]

The IPv4 and IPv6 SNAT maps are only used if BPF NodePort is enabled.
Commit cac5218 ("datapath: remove SNAT maps entries when kube-proxy is
enabled") removed the maps on startup if BPF NodePort is disabled.

We were however still creating them regardless of the BPF NodePort
status. The creation started a controller which then fails once the
actual map is removed. This commit fixes the issue by not creating the
userspace object, including the controller, for the SNAT maps when BPF
NodePort is disabled.

Fixes: cac5218 ("datapath: remove SNAT maps entries when kube-proxy is
enabled")
Fixes: cilium#15141
Signed-off-by: Paul Chaignon <paul@cilium.io>
[ upstream commit 2b6e04f ]

Signed-off-by: Sean Winn <sean@isovalent.com>
Signed-off-by: Paul Chaignon <paul@cilium.io>
@pchaigno pchaigno requested a review from a team as a code owner March 10, 2021 09:48
@pchaigno pchaigno added backport/1.9 kind/backports This PR provides functionality previously merged into master. labels Mar 10, 2021
@pchaigno
Copy link
Member Author

test-backport-1.9

@joestringer
Copy link
Member

CI is green except for Travis, which failed to trigger. I'll close&reopen to see if that triggers the run.

@joestringer joestringer reopened this Mar 10, 2021
@pchaigno
Copy link
Member Author

I also validated that the unit tests pass locally (for amd64 at least).

@pchaigno
Copy link
Member Author

CI was previously green except for Travis CI. Travis CI is now green. I think this is ready to merge.

@pchaigno pchaigno added the ready-to-merge This PR has passed all tests and received consensus from code owners to merge. label Mar 10, 2021
@joestringer joestringer merged commit da19d74 into cilium:v1.9 Mar 10, 2021
@joestringer
Copy link
Member

@pchaigno the command in the PR description updates the statuses of the wrong PRs ;) I manually fixed up the labels to reflect reality.

@pchaigno
Copy link
Member Author

@pchaigno the command in the PR description updates the statuses of the wrong PRs ;) I manually fixed up the labels to reflect reality.

Whoops! All looks good now, thanks!

@pchaigno pchaigno deleted the pr/v1.9-backport-2021-03-10 branch March 10, 2021 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/backports This PR provides functionality previously merged into master. ready-to-merge This PR has passed all tests and received consensus from code owners to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants