Isolate direct routing device functionality #32381
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bf6917e to
2970dc9
Compare
9da4168 to
baf7736
Compare
|
/test |
baf7736 to
b072294
Compare
|
/test |
b072294 to
4a44ed6
Compare
|
/ci-runtime |
4a44ed6 to
2e8bb85
Compare
|
/test |
2e8bb85 to
7bdd6a9
Compare
|
/test |
Closed
3986d9a to
b9d1b40
Compare
|
/test |
7e2da1a to
9ab8810
Compare
|
/test |
2efccbf to
e0b52cc
Compare
1f9358d to
57d03bb
Compare
|
/test |
57d03bb to
197c776
Compare
|
/test |
197c776 to
25cc179
Compare
|
/test |
We explicitly disallow enabling IPv6 NDP without setting an IPv6 multicast device in config validation, hence this code was unreachable. Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
This cell contains the logic to choose the direct routing device, based on the users configuration or falling back to "autodetecting" the right device. Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
Removes the device manager shim as the only functionality that remained was choosing the direct routing device. That logic is now contained in the direct routing device cell, which is used treewide to find the device to use. Adds the direct routing device to the LocalNodeConfiguration used in the loader and related subsystems. Signed-off-by: David Bimmler <david.bimmler@isovalent.com> Signed-off-by: Jussi Maki <jussi@isovalent.com>
The (default) alloc range initialization was moved from the local_node_sync.go to later in the startup process. This means that node.LocalNode can be observed with empty alloc ranges instead of the "default ranges". As the "default range" is not really useful it's better to instead wait for the proper alloc ranges anyway. Complication here is that in ClusterPool IPAM the alloc ranges are set by the operator into CiliumNode CRD, but the agent needs to first create it. Thus it's not easy to move this logic into local_node_sync.go yet. Instead, let's do the next best thing and just wait for the alloc ranges to be set in the iptables reconciler. Signed-off-by: Jussi Maki <jussi@isovalent.com>
25cc179 to
dd6d4d5
Compare
|
/test |
3 tasks
pippolo84
added a commit
to pippolo84/cilium
that referenced
this pull request
Jun 20, 2025
This reverts commit 2fc52eb. The commit was added with the intent to have an uniform behavior when Cilium is started on a single stack cluster with ipv6 support enabled, despite the KPR setting being enabled or disabled. Specifically, the added check was stopping the agent startup in case of a missing IPv6 address on the node, even when KPR was disabled. However, the IPv6 detection for NodePort, responsible for the startup error in case of missing IPv6 address with KPR enabled, has been removed in cilium#29033. Therefore, there is no reason anymore to stop the agent at startup when the IPv6 support is enabled and the node is missing an IPv6 address. Moreover, the commit above led to some unintended consequences in environments where KPR is disabled and the IPv6 address is set on the node after the Cilium agent is started (see cilium#34861). The same unintended consequence became more frequent after cilium#32381, where we moved later in the daemon startup process the first call to SetDefaultPrefix. That function, among other things, was in charge of setting up a temporary IPv6 Unique Local Address in case the node does not have one yet. Since now the agent does this later (specifically, while configuring IPAM), the check introduced in 2fc52eb sees the IPv6 node address as nil and stops the agent. Therefore, revert the check to avoid the unintended regressions. Related: cilium#28953 Related: cilium#34861 Related: cilium#29033 Related: cilium#32381 Fixes: cilium#37817 Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>
pippolo84
added a commit
to pippolo84/cilium
that referenced
this pull request
Jun 23, 2025
This reverts commit 2fc52eb. The commit was added with the intent to have an uniform behavior when Cilium is started on a single stack cluster with ipv6 support enabled, despite the KPR setting being enabled or disabled. Specifically, the added check was stopping the agent startup in case of a missing IPv6 address on the node, even when KPR was disabled. However, the IPv6 detection for NodePort, responsible for the startup error in case of missing IPv6 address with KPR enabled, has been removed in cilium#29033. Therefore, there is no reason anymore to stop the agent at startup when the IPv6 support is enabled and the node is missing an IPv6 address. Moreover, the commit above led to some unintended consequences in environments where KPR is disabled and the IPv6 address is set on the node after the Cilium agent is started (see cilium#34861). The same unintended consequence became more frequent after cilium#32381, where we moved later in the daemon startup process the first call to SetDefaultPrefix. That function, among other things, was in charge of setting up a temporary IPv6 Unique Local Address in case the node does not have one yet. Since now the agent does this later (specifically, while configuring IPAM), the check introduced in 2fc52eb sees the IPv6 node address as nil and stops the agent. Therefore, revert the check to avoid the unintended regressions. Related: cilium#28953 Related: cilium#34861 Related: cilium#29033 Related: cilium#32381 Fixes: cilium#37817 Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 23, 2025
This reverts commit 2fc52eb. The commit was added with the intent to have an uniform behavior when Cilium is started on a single stack cluster with ipv6 support enabled, despite the KPR setting being enabled or disabled. Specifically, the added check was stopping the agent startup in case of a missing IPv6 address on the node, even when KPR was disabled. However, the IPv6 detection for NodePort, responsible for the startup error in case of missing IPv6 address with KPR enabled, has been removed in #29033. Therefore, there is no reason anymore to stop the agent at startup when the IPv6 support is enabled and the node is missing an IPv6 address. Moreover, the commit above led to some unintended consequences in environments where KPR is disabled and the IPv6 address is set on the node after the Cilium agent is started (see #34861). The same unintended consequence became more frequent after #32381, where we moved later in the daemon startup process the first call to SetDefaultPrefix. That function, among other things, was in charge of setting up a temporary IPv6 Unique Local Address in case the node does not have one yet. Since now the agent does this later (specifically, while configuring IPAM), the check introduced in 2fc52eb sees the IPv6 node address as nil and stops the agent. Therefore, revert the check to avoid the unintended regressions. Related: #28953 Related: #34861 Related: #29033 Related: #32381 Fixes: #37817 Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 23, 2025
This reverts commit 2fc52eb. The commit was added with the intent to have an uniform behavior when Cilium is started on a single stack cluster with ipv6 support enabled, despite the KPR setting being enabled or disabled. Specifically, the added check was stopping the agent startup in case of a missing IPv6 address on the node, even when KPR was disabled. However, the IPv6 detection for NodePort, responsible for the startup error in case of missing IPv6 address with KPR enabled, has been removed in #29033. Therefore, there is no reason anymore to stop the agent at startup when the IPv6 support is enabled and the node is missing an IPv6 address. Moreover, the commit above led to some unintended consequences in environments where KPR is disabled and the IPv6 address is set on the node after the Cilium agent is started (see #34861). The same unintended consequence became more frequent after #32381, where we moved later in the daemon startup process the first call to SetDefaultPrefix. That function, among other things, was in charge of setting up a temporary IPv6 Unique Local Address in case the node does not have one yet. Since now the agent does this later (specifically, while configuring IPAM), the check introduced in 2fc52eb sees the IPv6 node address as nil and stops the agent. Therefore, revert the check to avoid the unintended regressions. Related: #28953 Related: #34861 Related: #29033 Related: #32381 Fixes: #37817 Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>
viktor-kurchenko
pushed a commit
that referenced
this pull request
Jun 25, 2025
[ upstream commit dfd8f93 ] This reverts commit 2fc52eb. The commit was added with the intent to have an uniform behavior when Cilium is started on a single stack cluster with ipv6 support enabled, despite the KPR setting being enabled or disabled. Specifically, the added check was stopping the agent startup in case of a missing IPv6 address on the node, even when KPR was disabled. However, the IPv6 detection for NodePort, responsible for the startup error in case of missing IPv6 address with KPR enabled, has been removed in #29033. Therefore, there is no reason anymore to stop the agent at startup when the IPv6 support is enabled and the node is missing an IPv6 address. Moreover, the commit above led to some unintended consequences in environments where KPR is disabled and the IPv6 address is set on the node after the Cilium agent is started (see #34861). The same unintended consequence became more frequent after #32381, where we moved later in the daemon startup process the first call to SetDefaultPrefix. That function, among other things, was in charge of setting up a temporary IPv6 Unique Local Address in case the node does not have one yet. Since now the agent does this later (specifically, while configuring IPAM), the check introduced in 2fc52eb sees the IPv6 node address as nil and stops the agent. Therefore, revert the check to avoid the unintended regressions. Related: #28953 Related: #34861 Related: #29033 Related: #32381 Fixes: #37817 [ Backporter's notes: - resolved conflict in: daemon/k8s/init.go ] Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: viktor-kurchenko <viktor.kurchenko@isovalent.com>
wanglei4687
pushed a commit
to wanglei4687/cilium
that referenced
this pull request
Jun 26, 2025
This reverts commit 2fc52eb. The commit was added with the intent to have an uniform behavior when Cilium is started on a single stack cluster with ipv6 support enabled, despite the KPR setting being enabled or disabled. Specifically, the added check was stopping the agent startup in case of a missing IPv6 address on the node, even when KPR was disabled. However, the IPv6 detection for NodePort, responsible for the startup error in case of missing IPv6 address with KPR enabled, has been removed in cilium#29033. Therefore, there is no reason anymore to stop the agent at startup when the IPv6 support is enabled and the node is missing an IPv6 address. Moreover, the commit above led to some unintended consequences in environments where KPR is disabled and the IPv6 address is set on the node after the Cilium agent is started (see cilium#34861). The same unintended consequence became more frequent after cilium#32381, where we moved later in the daemon startup process the first call to SetDefaultPrefix. That function, among other things, was in charge of setting up a temporary IPv6 Unique Local Address in case the node does not have one yet. Since now the agent does this later (specifically, while configuring IPAM), the check introduced in 2fc52eb sees the IPv6 node address as nil and stops the agent. Therefore, revert the check to avoid the unintended regressions. Related: cilium#28953 Related: cilium#34861 Related: cilium#29033 Related: cilium#32381 Fixes: cilium#37817 Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>
viktor-kurchenko
pushed a commit
that referenced
this pull request
Jun 26, 2025
[ upstream commit dfd8f93 ] This reverts commit 2fc52eb. The commit was added with the intent to have an uniform behavior when Cilium is started on a single stack cluster with ipv6 support enabled, despite the KPR setting being enabled or disabled. Specifically, the added check was stopping the agent startup in case of a missing IPv6 address on the node, even when KPR was disabled. However, the IPv6 detection for NodePort, responsible for the startup error in case of missing IPv6 address with KPR enabled, has been removed in #29033. Therefore, there is no reason anymore to stop the agent at startup when the IPv6 support is enabled and the node is missing an IPv6 address. Moreover, the commit above led to some unintended consequences in environments where KPR is disabled and the IPv6 address is set on the node after the Cilium agent is started (see #34861). The same unintended consequence became more frequent after #32381, where we moved later in the daemon startup process the first call to SetDefaultPrefix. That function, among other things, was in charge of setting up a temporary IPv6 Unique Local Address in case the node does not have one yet. Since now the agent does this later (specifically, while configuring IPAM), the check introduced in 2fc52eb sees the IPv6 node address as nil and stops the agent. Therefore, revert the check to avoid the unintended regressions. Related: #28953 Related: #34861 Related: #29033 Related: #32381 Fixes: #37817 [ Backporter's notes: - resolved conflict in: daemon/k8s/init.go ] Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: viktor-kurchenko <viktor.kurchenko@isovalent.com>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 26, 2025
[ upstream commit dfd8f93 ] This reverts commit 2fc52eb. The commit was added with the intent to have an uniform behavior when Cilium is started on a single stack cluster with ipv6 support enabled, despite the KPR setting being enabled or disabled. Specifically, the added check was stopping the agent startup in case of a missing IPv6 address on the node, even when KPR was disabled. However, the IPv6 detection for NodePort, responsible for the startup error in case of missing IPv6 address with KPR enabled, has been removed in #29033. Therefore, there is no reason anymore to stop the agent at startup when the IPv6 support is enabled and the node is missing an IPv6 address. Moreover, the commit above led to some unintended consequences in environments where KPR is disabled and the IPv6 address is set on the node after the Cilium agent is started (see #34861). The same unintended consequence became more frequent after #32381, where we moved later in the daemon startup process the first call to SetDefaultPrefix. That function, among other things, was in charge of setting up a temporary IPv6 Unique Local Address in case the node does not have one yet. Since now the agent does this later (specifically, while configuring IPAM), the check introduced in 2fc52eb sees the IPv6 node address as nil and stops the agent. Therefore, revert the check to avoid the unintended regressions. Related: #28953 Related: #34861 Related: #29033 Related: #32381 Fixes: #37817 [ Backporter's notes: - resolved conflict in: daemon/k8s/init.go ] Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: viktor-kurchenko <viktor.kurchenko@isovalent.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This moves the resolving of the DirectRoutingDevice into its own component allowing us to finally remove the
DeviceManagershim.