-
Notifications
You must be signed in to change notification settings - Fork 3.4k
helm: Fix duplicate tunnel-protocol configuration in cilium-config configmap #36226
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
helm: Fix duplicate tunnel-protocol configuration in cilium-config configmap #36226
Conversation
Commit ab036db does not match "(?m)^Signed-off-by:". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
ab036db
to
da0bfdc
Compare
Commit ab036db does not match "(?m)^Signed-off-by:". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
da0bfdc
to
a5ae039
Compare
3a50837
to
cce49a9
Compare
cce49a9
to
00229ab
Compare
I added the release-note by editing the initial comment, but the label did not get removed. Please let me know if I should add something to this PR etc. |
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 for the PR! Unfortunately this is a breaking change - we either need to come up with a solution that doesn't break existing installation commands - or patch all the docs and tooling before we can ship this PR.
00229ab
to
2af7447
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 looks better to me! I think we should also get a review from @giorio94 to make sure we're fine with tunnel-protocol: vxlan
if the user specifies an explicitly sets the native routing mode (I believe it should be fine since the agent also defaults to that)
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. Changes look good to me, just a couple of comments inline.
I think we should also get a review from @giorio94 to make sure we're fine with
tunnel-protocol: vxlan
if the user specifies an explicitly sets the native routing mode (I believe it should be fine since the agent also defaults to that)
Yes, the agent defaults to vxlan as tunnel protocol in all cases, so that's consistent.
cilium/pkg/datapath/tunnel/tunnel.go
Lines 235 to 238 in 89c98fb
var defaultConfig = userCfg{ | |
TunnelProtocol: defaults.TunnelProtocol, | |
TunnelPort: 0, // auto-detect based on the protocol. | |
} |
cilium/pkg/defaults/defaults.go
Lines 514 to 515 in 89c98fb
// TunnelProtocol is the default tunneling protocol | |
TunnelProtocol = "vxlan" |
2af7447
to
fbc81f4
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.
Looks good to me now, thank you! I think we can drop the aksbyocni check too
After that, let's see what CI says
Previously the tunnel-protocol was limited to VXLAN, when enabling aksbyocni. As discussed in cilium#36226 (comment) this seems to be a leftover from when there was just one flag called "tunnel" that combined routing-mode and tunnel-protocol. This patch makes it possible to configure any tunnel-protocol with aksbyocni.enabled: true. Related: cilium#24561 Signed-off-by: Jonas Badstübner <jonas@jb.software>
Should I add the change for allowing all tunnelProtocols now to the release-notes as well? |
/test |
Previously it was only possible to enable geneve with tunnel routing mode by explicitly setting both as helm values. Otherwise it would fail like this: line 132: mapping key "tunnel-protocol" already defined at line 131 Fixes cilium#33456 Signed-off-by: Jonas Badstübner <jonas@jb.software>
Previously the tunnel-protocol was limited to VXLAN, when enabling aksbyocni. As discussed in cilium#36226 (comment) this seems to be a leftover from when there was just one flag called "tunnel" that combined routing-mode and tunnel-protocol. This patch makes it possible to configure any tunnel-protocol with aksbyocni.enabled: true. Related: cilium#24561 Signed-off-by: Jonas Badstübner <jonas@jb.software>
b02f6e5
to
f681254
Compare
Sorry for aborting the tests, probably should have waited for them to finish. |
/test |
Restarted failed CI (failures are common flakes unrelated to the PR) |
Please ensure your pull request adheres to the following guidelines:
description and a
Fixes: #XXX
line if the commit addresses a particularGitHub issue.
Fixes: <commit-id>
tag, thenplease add the commit author[s] as reviewer[s] to this issue.
We had trouble setting this up too, and as @haribhusal2025 stated in #33456 (comment), setting the routingMode and tunnelProtocol explicitly works around the helm templating issues.
I am aware of #34315 attempting to fix this issue, but I think the approach of using a variable and overwriting it, is not the best for user experience.
As a heavy user of helm, having to look at the helm template itself to know what is happening or where values come from is more frustrating than simply being shown an error.
So I propose a solution to the problem that gives an early error message, without introducing more edge cases to check for with nested if-statements.
Fixes: #33456
Closes: #34315