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
Change routing-mode and tunnel-protocol based on .Values.tunnel and .Values.routingMode #27841
Conversation
Commit 8636098a7e5ec3b8b2a67a607c41124b0e900966 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 |
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! Overall looks good, and most combinations work, but I've found that specifying both a routing mode and a tunnel protocol did not work as expected, e.g. --set tunnel=geneve --set routingMode=tunnel
did not set the tunnel-protocol
correctly, which I think it should also do.
Also, the commit subject is overly long, thus causing checkpatch.pl
to fail in CI. Could you shorten it a bit and instead put the details in the commit message description? Thanks
@pchaigno Would you mind giving this a quick look too if the flag combinations are still working as intended? |
The way I see it, What if someone sets Since The only case in which |
8d424fb
to
64e1f86
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.
Since tunnel is deprecated, it should be ignored when (the new) routingMode and tunnelProtocol are set.
Yeah I think you are right, I missed the fact that tunnel
has been replaced by tunnelProtocol
in Helm too.
I wonder if we should introduce some additional validations that disallow tunnelProtocol
without a routing mode, or tunnel
with routingMode
.
At the moment, if I specify --set tunnelProtocol=geneve
without routingMode
, it generates the following for some reason:
# Encapsulation mode for communication between nodes
# Possible values:
# - disabled
# - vxlan (default)
# - geneve
# Default case
routing-mode: "tunnel"
tunnel-protocol: "vxlan"
tunnel-protocol: "geneve"
Yes, agreed. I'll add the validation you mentioned. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Great! Could you remove the validation commits instead of reverting them clean history on the main branch? Thanks! |
@gandro anything else? |
No, this looks good to me know! Thanks again, let's wait for the other CODEOWNERs to review. |
The tunnel option is deprecated and will be removed in Cilium v1.15. This commit fixes the remaining uses I have found where the Cilium CLI still set the old `tunnel` flag unconditionally, which will lead to issues once the flag is no longer accepted [1]. The Cilium CLI now only uses the deprecated `tunnel` flag for Cilium versions 1.13 and older. When reading the ConfigMap (such as in the clustermesh code), we attempt to first parse the new values, before falling back on the old ones. [1] cilium/cilium#27841 (comment) Signed-off-by: Sebastian Wicki <sebastian@isovalent.com>
The tunnel option is deprecated and will be removed in Cilium v1.15. This commit fixes the remaining uses I have found where the Cilium CLI still set the old `tunnel` flag unconditionally, which will lead to issues once the flag is no longer accepted [1]. The Cilium CLI now only uses the deprecated `tunnel` flag for Cilium versions 1.13 and older. When reading the ConfigMap (such as in the clustermesh code), we attempt to first parse the new values, before falling back on the old ones. [1] cilium/cilium#27841 (comment) Signed-off-by: Sebastian Wicki <sebastian@isovalent.com>
The tunnel option is deprecated and will be removed in Cilium v1.15. This commit fixes the remaining uses I have found where the Cilium CLI still set the old `tunnel` flag unconditionally, which will lead to issues once the flag is no longer accepted [1]. The Cilium CLI now only uses the deprecated `tunnel` flag for Cilium versions 1.13 and older. When reading the ConfigMap (such as in the clustermesh code), we attempt to first parse the new values, before falling back on the old ones. [1] cilium/cilium#27841 (comment) Signed-off-by: Sebastian Wicki <sebastian@isovalent.com>
cilium/cilium#27841 changed how the routing mode gets set for GKE, and now it always gets set to "native". Use --datapath-mode flag to force the tunnel mode for the external workload test since that's the only configuration that's known to work [^1]. Fixes: #2070 [^1]: https://docs.cilium.io/en/latest/network/external-workloads/ Signed-off-by: renovate[bot] <bot@renovateapp.com> Signed-off-by: Michi Mutsuzaki <michi@isovalent.com>
cilium/cilium#27841 changed how the routing mode gets set for GKE, and now it always gets set to "native". Use --datapath-mode flag to force the tunnel mode for the external workload test since that's the only configuration that's known to work [^1]. Fixes: #2070 [^1]: https://docs.cilium.io/en/latest/network/external-workloads/ Signed-off-by: renovate[bot] <bot@renovateapp.com> Signed-off-by: Michi Mutsuzaki <michi@isovalent.com>
Fixes #27756