https://github.com/cilium/cilium

sort by:
Revision Author Date Message Commit Date
4a4fa05 Prepare for release v1.14.6 Signed-off-by: Maxim Mikityanskiy <maxim@isovalent.com> 18 January 2024, 12:04:39 UTC
c776b3a bugtool: include `cilium-dbg bgp routes advertised` commands [ upstream commit 6e11c6c3e721649d3c7590350bdf61789a5c3e52 ] Includes cilium-dbg commands for dumping IPv4 and IPv6 advertised BGP routes of each configured BGP peer in the bugtool. Signed-off-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
3ab5573 cilium-dbg: Allow executing `bgp routes advertised` without peer IP [ upstream commit 55a49f195635dd86632a0f55edbd01b5f56728f0 ] This enhances the `cilium-dbg bgp routes` command to allow listing advertised routes without the need to specify an exact peer IP - in that case, advertised routes of all peers will be listed. Also adds defaulting of table type and AFI / SAFI, to allow simple use with even less typing. Signed-off-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
d2c5ac0 bgpv1: Allow retrieving advertised routes for all peers in GetRoutes API [ upstream commit 134d88fa797b1d5fcb4bea12ebe7d99ce22ebf23 ] [ backporter's note: types.ParseTableType() call replaced with api.ToAgentTableType() in BGP manager code, as this has been moved/renamed in upstream ] This enhances the BGP GetRoutes API to allow retrieving advertised BGP routes for all configured peers, without the need for specifying an exact peer address. The peer address is included in the BgpRoute response in case that the source of the route is adj-rib-in or adj-rib-out. Signed-off-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
b2a2c86 bugtool: Add "cilium bgp peers" & "cilium bgp routes" command outputs [ upstream commit 38759979ad1009cf4d60ef3b940bff08c13c3f28 ] Includes "cilium bgp peers" & "cilium bgp routes" command outputs in the bugtool so that BGP info is available in sysdumps. Signed-off-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
8f4c128 bgpv1: Gracefully handle bgp peers/routes API/CLI if BGP CP is disabled [ upstream commit 2d8db59b8b29b7823ce79a57f5dcb4fb2f5330aa ] [ backporter's note: slightly modified nil checks in daemon/cmd/bgp.go due to difference in API handlers implementation in v1.14 ] Fixes an issue with bgp/peers & bgp/routes API endpoint and cilium "bgp peers" & "bgp routes" CLI command when BGP Control Plane is disabled. Instead of returning an internal server error returns an specific error that can be properly handled in the CLI command code. Signed-off-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
8445e8d bgpv1: Implement `cilium bgp routes` command [ upstream commit 98ca33e12bafb3804143f33fa0e1ab7de1380fc3 ] Implement `cilium bgp routes` command that retrieves routes from bgp/routes API and displays response. Also allow using "peer" and "neighbor" keyword interchangeably in bgp CLI (e.g. "cilium bgp peers" == "cilium bgp neighbors", "cilium bgp routes ... peer 172.0.0.1" == "cilium bgp routes ... neighbor 172.0.0.1"). Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> Co-authored-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
79e0c8e api,bgpv1: Implement bgp/routes API [ upstream commit 1f5224517c49604d064bfc2236d2073cb0e02a35 ] [ backporter's note: adjusted API handler in daemon/cmd/bgp.go and its wiring in daemon, as v1.14 does not use the API handlers cell for that yet ] Implement bgp/routes API by wiring-up API call with BGPRouterManager. Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> Co-authored-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
60d764b bgpv1: Add a new API endpoint bgp/routes [ upstream commit 0a80d5cd69ecba7d5319b527a8a5962c404854ab ] Add a new API endpoint bgp/routes to retrieve BGP CPlane's RIB from API. The actual implementation will be in subsequent commits. Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> Co-authored-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
ecb8912 bgpv1: Add GetRoutes method to Router interface [ upstream commit 7fb8fb5dbc342014b77dfec5e5549aaca10a5472 ] Add a new GetRoutes method to the Router interface. This method retrieves routes from unerlying router's RIB. It supports retrieving Loc-RIB as well as Adj-RIB-In/Out. Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> Co-authored-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
df2b413 bgpv1: Add generic Path type [ upstream commit 9010462a7c361f2de6584c9f5cb94188c936faac ] Add a new generic Path type that which is an analogue of the GoBGP's Path object, but only contains a minimal fields required for Cilium's usecases. It consists of NLRI, Path Attributes and some status fields. We are relying on the GoBGP's pkg/packet/bgp package which is a generic BGP library (say net.IP package, but for BGP). We decided to reuse this library as a part of our router-independent intermediate representation because it's too painful for us to reinvent the BGP library by ourselves. This type will be used for implementing various BGP CPlane functionalities like retrieving the route. Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> Co-authored-by: Rastislav Szabo <rastislav.szabo@isovalent.com> 17 January 2024, 16:07:10 UTC
594df7b loader: fix obsolete XDP program removal [ upstream commit ea7c375d6c879f39fc91d53d08a41c3ba53bf2a7 ] [ Backporter's notes: had to address conflicts around `xdpConfigModeToFlag()` and applying it's usage in `attachProgram()` and `maybeUnloadObsoleteXDPPrograms()` ] This commit fixes a bug where `maybeUnloadObsoleteXDPPrograms()` removes XDP programs after a restart that are still in use and should remain in place. This can cause intermittent connectivity issues. The issue is that the kernel returns different values when it is queried for the attach mode of a netlink device compared to the values used when configuring the attach mode. E.g. when attaching with `XDPDriverMode` which evaluates to '4' in the input flags, querying it will return `XDP_ATTACHED_DRV` which evaluates to '1'. So when `maybeUnloadObsoleteXDPPrograms()` compares the queried values to the used input values there can be a mismatch which leads to cilium removing still needed XDP programs. This commit also changes the test, to be a suitable regression test for this fix. Previously the test was using `XDPGenericMode`. Unfortunately in this case the returned value from the kernel when querying netlink devices is `XDP_ATTACHED_SKB`, and both constants evaluate to '2' which is why this bug wasn't caught by the test in the first place. Fixes: #30132 Signed-off-by: Robin Gögge <r.goegge@isovalent.com> 17 January 2024, 16:06:54 UTC
59106b3 loader: return link.XDPAttachFlags from xdpModeToFlag [ upstream commit de46ed8a6ff22b287658c05b8207a02444554b8c ] Signed-off-by: Timo Beckers <timo@isovalent.com> 17 January 2024, 16:06:54 UTC
e50463f docs: fix chained veth plugin example [ upstream commit a25599704764c8e2c8dfbda78808a3c57f7499df ] We previously looked up the chaining mode by name, but this is non-obvious and unnecessary. So, we added the CHI chaining-mode parameter. But, we failed to update the docs to reference this. Fixes: #28714 Signed-off-by: Casey Callendrello <cdc@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 17 January 2024, 10:28:43 UTC
ddfe079 fix: remove help message in build config failure [ upstream commit 9907af3edd9c6bfb60cddffe130c80abae38537e ] Fixes: #28158 Signed-off-by: Vipul Singh <singhvipul@microsoft.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 17 January 2024, 10:28:43 UTC
258ecf4 Remove non fatal errors from SPIRE client in operator [ upstream commit 284b41d71c202f9149a545fc19ca323cc406a498 ] This removed level=error errors from the spire-client system in the operator. As it is expected to fail on initial startup of SPIRE to have connection issues Cilium will retry. Some errors also came from the SPIFFE library itself which is why a wrapper to log them as warnings instead was added. Signed-off-by: Maartje Eyskens <maartje.eyskens@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 17 January 2024, 10:28:43 UTC
11876e9 workflows: Increase IPsec e2e test's timeout [ upstream commit 680b0d11591c31988ba576150486bd9294c5e589 ] Bump the timeout to fix cancelled test runs that have started to pop up in CI. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 17 January 2024, 10:28:43 UTC
3062907 Do not handle mutual auth for reserved ids [ upstream commit e71407b09cd7e82e3772708a8d99e11a1a10c2ad ] This change adds a check in the auth manager not to do authentication for either IDs if they are reserved. This could have caused failed handshakes to happen should any of these entities be allowed by policy but with mutual auth enabled. These IDs do are not able to ever complete a handshake as they are not generated by design. This commit also replaces all IDs used in tests to be high enough that they do not conflict with reserve IDs. Signed-off-by: Maartje Eyskens <maartje@eyskens.me> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 17 January 2024, 10:28:43 UTC
7dfc686 option: Add --dnsproxy-enable-transparent-mode (default false) [ upstream commit 35162d1fb57c6aaeb8a57d3ec866625f1a2838b5 ] Add dnsproxy-enable-transparent-mode option to enable DNS Proxy transparent mode. If 'true', Cilium DNS proxy will use the original source address of the source pod in the forwarded DNS requests. Local host sources and destinations are excepted due to networking stack compatibility reasons, but the use of the original address is typically not significant for node local traffic. Defaults to 'false' for backwards compatibility for upgrades, or to 'true' for Cilium 1.12 onwards. Transparent mode is not compatible with CNI chaning modes, so if CNI chaining is used, transparent mode will not be set unless explicitly set with helm value 'dnsProxy.enableTransparentMode=true'. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> 16 January 2024, 08:58:26 UTC
165f5af dnsproxy: Do not use original source when not possible [ upstream commit 824e969f26d8bc68ee1a00cddbe25c29a876544c ] Do not use original source for server running in the local node, or when the destination is outside of the cluster, as there is a risk of missing masquarade on the upstream connection. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> 16 January 2024, 08:58:26 UTC
6404497 dnsproxy: Use original source address in connections to dns servers [ upstream commit 94f6553f5b79383b561e8630bdf40bd824769ede ] Set transparent, reuseaddr, and reuseport options and use the original source address on connections from DNS proxy to DNS servers to allow use of non-local source address as well as recreate sockets on the same 5-tuple without needing to wait for the TCP TIME_WAIT to finish. Use the MagicMarkEgress mark on connections to the dns servers instead the generic MagicMarkIdentity. Use original source address in connections to dns servers when the source address is not one of the host IPs. The original source address and port can not be reused if there is already socket with them to the same destination on the same networking namespace. Use new dns.SharedClients to reuse DNS clients between all requests that originate from the same source address and port. This allows multiple different requests to be pending at the same time on the same dns Client, which happens whenever the source pod sends multiple DNS requests from the same resolver invocation, e.g., for A and AAAA records. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> 16 January 2024, 08:58:26 UTC
5f6b6e1 pkg/node/manager: Do not delete ipset entry if just added on node update [ upstream commit cbe30378f752eb0295426a0e6bae34b4c7292e67 ] With iptable-based masquerading, we use some iptables rules to exclude certain flows from masquerading. These rules rely on IP sets (managed with ipset). There are some cases where we create entries and immediately remove them afterwards. The issue only occurs for the extra Kubernetes IPs) not the CiliumInternalIP) on the node, and only with both node encryption disabled and --enable-remote-node-identity=false. Here is a trimmed version of the previous code to follow the logics. When we update an existing node, and that the configuration is such that nodeAddressSkipsIPCache() returns true, then we create an ipset entry and immediately delete it after. Follow the numeroted comments in the code: func (m *manager) legacyNodeIpBehavior() bool { if m.conf.RemoteNodeIdentitiesEnabled() { return false } if m.conf.NodeEncryptionEnabled() { return false } return true } func (m *manager) nodeAddressSkipsIPCache(address nodeTypes.Address) bool { return m.legacyNodeIpBehavior() && address.Type != addressing.NodeCiliumInternalIP } func (m *manager) NodeUpdated(n nodeTypes.Node) { for _, address := range n.IPAddresses { // 1) We add the IP to the ipset if m.conf.NodeIpsetNeeded() && address.Type == addressing.NodeInternalIP { m.ipsetMgr.AddToNodeIpset(address.IP) } // 2) Say we skip the ipcache update here based on config... if m.nodeAddressSkipsIPCache(address) { continue } ... // 3) ... Then we don't add the IP to nodeIPsAdded, even though we added it to the ipset nodeIPsAdded = append(nodeIPsAdded, prefix) } ... entry, oldNodeExists := m.nodes[nodeIdentifier] if oldNodeExists { ... // 4) We call m.removeNodeFromIPCache(), passing nodeIPsAdded m.removeNodeFromIPCache(oldNode, resource, nodeIPsAdded, healthIPsAdded, ingressIPsAdded) ... } ... } func (m *manager) removeNodeFromIPCache(oldNode nodeTypes.Node, resource ipcacheTypes.ResourceID, nodeIPsAdded, healthIPsAdded, ingressIPsAdded []netip.Prefix) { ... for _, address := range oldNode.IPAddresses { oldPrefix := ip.IPToNetPrefix(address.IP) // 5) oldPrefix is not in nodeIPsAdded, we don't loop yet, we carry on to 6) if slices.Contains(nodeIPsAdded, oldPrefix) { continue } // 6) We remove the ipset entry that we just added if m.conf.NodeIpsetNeeded() && address.Type == addressing.NodeInternalIP { m.ipsetMgr.RemoveFromNodeIpset(address.IP) } if m.nodeAddressSkipsIPCache(address) { continue } ... } ... } This looks incorrect. If we just created the entry, we should keep it. Worse, if the node exists, and we try to create the ipset entry, then the ipset invocation will be a no-op because ipset won't add a duplicate entry, but then removing the entry just after that will remove the initial entry from node creation and may impact masquerading on the node. How do we change this? There are a comple of things that we can consider: - We can move 3) towards 1), before 2). In other words: we can update nodeIPsAdded as soon as we insert the ipset entry, making this list consistent with the ipset entries we created. However, this is incorrect, because if we skip the ipcache entry insertion in 2), then the list in nodeIPsAdded is inconsistent regarding the ipcache. - Another option would be to move 1) towards 3), after 2). In other words, insert the new ipset entry only if we do not skip the ipcache update, thus tying the creation of the ipset and ipcache entries together. However, this would change the current behaviour, and is not the desirable outcome: we want to skip masquerading for the NodeInternalIP (by adding the corresponding entry to the ipset) regardless of whether remote node identities are set or not (thanks to Paul Chaignon for the clarification here). - Given that we want to preserve the current dissociation between the insertion of the ipset and ipcache entries, we need a separate list. Therefore, this commit addresses the issue by adding a separate slice to record the ipset entries we created during the node update, to avoid removing any of them even if we skip the ipcache update. Historically: - Commit 49cb220626b8 ("iptables: Don't masquerade traffic to cluster nodes") introduced the ipset entry creation. It's fine because we wouldn't ever remove the ipset entries on node updates, so we could 1) add the ipset entry, 2) skipIPCache() and avoid updating ipsAdded, since we didn't use ipsAdded for ipset operations. - Commit d5e5bf3485d4 ("node/manager: Remove ipset config from previous node state") introduced the issue, because it adds the ipset entry removal to NodeUpdated(), regardless of whether we just added the entry. - Commit e7e4abb422c8 ("node/manager: Only remove old IPs if they weren't already added") attempts to fix this, but is broken because 1) the slice lookup never succeed (fixed in f2a43127882d ("nodemanager: Move to async IPCache API")) and 2) ipsAdded may or may not contain the relevant entries, depending on whether we skipped the ipcache operations. Found by code inspection, while investigating CI flakes on branch v1.13 due to the slice lookups on ipsAdded never succeeding and the IP not being excluded from masquerading as we expected. Fixes: d5e5bf3485d4 ("node/manager: Remove ipset config from previous node state") Signed-off-by: Quentin Monnet <quentin@isovalent.com> 15 January 2024, 08:58:54 UTC
faa4e73 pkg/node/manager: Add test to validate ipset entries [ upstream commit 4a1bc1b7d3eaf795f92b8a1639817790c870bd8b ] Following a bug on the v1.13 branch in the way we update the list of ipset entries in the node manager, add a test to ensure that entries are added or removed as we expect on node updates. This is a forward port of the test added first to branch v1.13, commit 9ec163aff6f ("pkg/node/manager: Add test to validate ipset entries"), although the test has been reworked to use a mock ipset manager instead of checking the real ipset (which required privileges). [ Backport note: - Include "golang.org/x/exp/slices" instead of "slices" - Several other trivial conflicts ] Signed-off-by: Quentin Monnet <quentin@isovalent.com> 15 January 2024, 08:58:54 UTC
6c652e8 iptables: Expose ipset funcs as Manager methods [ upstream commit 7dc94b203f2d41a01c09bc2f61deed9f3103cb43 ] Move AddToNodeIpset and RemoveFromNodeIpset into the iptables manager, so that other cells depending on them will import the iptables config manager through dependency injection. [ Backport notes: Multiple minor conflicts - iptables.Manager is iptables.IptablesManager on v1.14 - cell.TestScope() is not passed to manager.New() on v1.14 - pkg/datapath/fake/cells.go is not present on v1.14 - No cell for iptables on v1.14, so we initialise the IptablesManager differently ] Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 15 January 2024, 08:58:54 UTC
436e670 gha: wait for cilium-test namespace deletion in conformance aks [ upstream commit b6192a97b7d1c670ced7b5f0b0655c65b29e84ab ] Add the wait flag to cilium uninstall in Conformance AKS, so that we ensure that the cilium-test namespace gets effectively deleted before uninstalling and reinstalling Cilium. This ensures that the connectivity tests can then be started correctly (i.e., that the namespace can be created) and prevents Cilium errors such as: msg="Cannot create CEP" error="... forbidden: unable to create new content in namespace cilium-test because it is being terminated" Finally, it brings also consistency with what we already do in the other workflows. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 15 January 2024, 08:51:40 UTC
9aab4bb Allow SPIRE agent on control plane [ upstream commit b193daaf34e7cd8e72691a139122deee8848fddf ] This sets the default toleration for SPIRE agent to be allowed on the control plane nodes. This allows Cilium Agent on these nodes to get attested by SPIRE for Mutual Authentication to work. Signed-off-by: Maartje Eyskens <maartje.eyskens@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 15 January 2024, 08:51:40 UTC
28c9127 envoy: add name label to ServiceMonitor. [ upstream commit 2f3e3ec8fbaaa4f31b0157d03f83066025be53e7 ] This commit adds the app.kubernetes.io/name label to cilium-envoy ServiceMonitor, matching the convention in cilium-operator. Signed-off-by: cornfeedhobo <cornfeedhobo@fuzzlabs.org> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 15 January 2024, 08:51:40 UTC
57ed9ea doc: Update Azure CNI by Cilium as one of recommended options [ upstream commit bf42e1ff23ee7e60d8a7af5301fb0cf2ecd89b71 ] Signed-off-by: Tamilmani <tamanoha@microsoft.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 15 January 2024, 08:51:40 UTC
8cf1fd8 bpf: use v3 mcpu for tests with 5.10 and 6.1 kernel [ upstream commit f8a761667c2eb18ba6cd392bdba9121c987f2267 ] We want to mimic GetBPFCPU(), which selects mcpu=v3 for 5.10+ kernels. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 15 January 2024, 08:51:40 UTC
f7a4dce bpf: add 6.1 kernel support for build tests [ upstream commit fc7b72f2c12f6c525a9aafaf70b4ddeba4869349 ] https://github.com/cilium/cilium/pull/29349 added complexity tests for 6.1. But we also want to select the relevant features for the build tests. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 15 January 2024, 08:51:40 UTC
3f99cbc fix(deps): update module golang.org/x/crypto to v0.17.0 [security] [ upstream commit 4ad57189e6e979669c7993995e73eac84179663c ] Signed-off-by: renovate[bot] <bot@renovateapp.com> 15 January 2024, 08:51:40 UTC
8e191cb ci: increase disk size for GKE clusters (ci-gke & ci-external-workloads) [ upstream commit 22c8acdfd57f167f09364b580f69653a44cf2d6d ] Some tests are failing due to PodEviction due to DiskPressure. Therefore, this commit is increasing the disk size of a GKE node from 10GB to 20GB. Fixes: #29312 Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 15 January 2024, 08:51:40 UTC
50c679f workflows: move cilium_cli_version definition to set-env-variables action [ upstream commit 42e1a4a129b9083a229489057c226f318a5f7ed6 ] Co-authored-by: Tobias Klauser <tobias@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 15 January 2024, 08:51:40 UTC
66d4a5c ci: conformance-e2e: ignore 'Host datapath not ready' drop reason [ upstream commit 7d897879c5de433830936e600f6b953c2a8f57b2 ] Signed-off-by: Timo Beckers <timo@isovalent.com> 12 January 2024, 15:13:04 UTC
36dedd6 bpf: Add 'host not ready' drop reason if host policy cannot be enforced [ upstream commit 20789ff662c83f5804287db6c25c9ff2102c037f ] bpf_lxc.c contains multiple tail calls into POLICY_CALL_MAP at the HOST_EP_ID slot. The program in this slot is provided by bpf_host.c. During first agent startup, there are often multiple Pods pending creation due to no CNI being available. As soon as the agent's local API becomes available, these outstanding CNI requests have a chance to be accepted by the API handler. If one such request is serviced before the host datapath controller has a chance to grab the compilation lock, the endpoint program will compile and attach first. If the host firewall is enabled, and this new workload endpoint sends a packet to the host, the host's ingress policy needs to be enforced. However, because bpf_host hasn't been loaded yet, this policy program is not yet present in POLICY_CALL_MAP, resulting in a missed tail call. One potential solution to this problem would be making sure the host datapath always attaches before workload endpoints do. There's one problem with this solution: clustermesh requires data from other clusters in order to correctly populate the local ipcache, and the ipcache currently needs to be populated for the host endpoint to finish attaching. It obtains this information through clustermesh-apiserver, typically deployed onto the local node as a regular Pod. This means workload endpoints must be able to deploy before the host endpoint. As a stop gap, tolerate these kinds of drops and assign them a specific meaning, without letting them spill over into the generic 'missed tail call' bucket. To stabilize end-to-end tests, we're aiming to enforce zero dropped tail calls in all CI scenarios, since it leads to packets that mysteriously go missing, introducing chaos that's impossible to troubleshoot. Signed-off-by: Timo Beckers <timo@isovalent.com> 12 January 2024, 15:13:04 UTC
547ed3b policy: Fix mapstate changes error in entry change comparison [ upstream commit 3d3f69ce3386d836ea45219239f0d69daea7af7a ] [ backporter's note: Fix a minor conflict comes from the variable name change (key -> ms).] Datapath equalness of the old and new entry must be evaluated before entries are merged, afterwards the entries will be the same and the key is not added in ChangeState.Adds, which may lead to a policy map entry not being updated during incremental updates. Fixes: #26331 Signed-off-by: Jarno Rajahalme <jarno@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
aea89d0 complexity-tests: add bpf_network configuration [ upstream commit e95f2e0ed8839e4b77343a97532484d461138139 ] [ backporter's note: - Makefile target structure is different between v1.14 and main. Took the v1.14's structure. - TRACE_NOTIFY is already defined in the bpf_align_checker.c. Avoid redefining it. ] Add an initial bpf_network configuration. The defines are taken from a sysdump for a failing CI run that seems to exhibit verifier problems. Signed-off-by: Lorenz Bauer <lmb@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
cdd6694 ipsec: ensure all trace events are discarded when mon. agg. is enabled [ upstream commit a495abda8528b8a07796dc1ff9f159bc0c64c028 ] [ backporter's note: backporter's note: Upstream calls do_netdev_encrypt_encap instead of wrapping it with do_netdev_encrypt. Use do_netdev_encrypt. ] This commit modifies calls to `send_trace_notify` in the datapath to drop trace events related to encrypted packets when monitor aggregation is enabled. More specifically, this commit ensures that whenever `send_trace_notify` is called with a `trace_reason` of `TRACE_REASON_ENCRYPTED`, the `monitor` argument is set to zero. A Coccinelle script is provided in this commit to add a build-time check for this requirement moving forward. This change helps to reduce the overall CPU usage of Cilium Agents when IPSec encryption is enabled, by reducing the number of trace events emitted by the datapath. Normally monitor aggregation can be used in order to reduce the number of trace events, however IPSec-related trace events are not able to be aggregated since they lack the necessary connection tracking information. See the function `emit_trace_notify` in `bpf/lib/trace.h` for more information. This same change was applied in `bpf/bpf_lxc.c` in commit 3e52822. Thank you to Lorenz who added a workaround for passing the verifier with Clang 10. See also: cilium/cilium#27168 Co-authored-by: Lorenz Bauer <lmb@isovalent.com> Signed-off-by: Ryan Drew <ryan.drew@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
16347e5 bpf: ipv4: always return drop reason from ipv4_handle_fragmentation() [ upstream commit 0d35af07d21178e267f136ce1f2184983399217b ] To make it easy for callers, ipv4_handle_fragmentation() should always return a DROP_* reason on error. But for errors from l4_load_ports() we're currently just propagating those raw errors back. Return a drop reason instead. This also makes us consistent with the non-fragment path in ipv4_load_l4_ports(). Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
002d29a hubble: Rate limit "stale identities observed" debug message [ upstream commit 4196935b35d9e4f6f5acdc2f91d173807fdef7d0 ] [ backporter's note: time package doesn't exist on v1.14 branch. Use standard time package instead. ] This limits the amount of "stale identities observed" messages to one every 30 seconds. This is particularly important if monitor aggregation is disabled, as otherwise any unknown discrepancy fills the log buffers and thus makes it hard to e.g. debug CI flakes. Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
0bc33dc hubble: Do not report stale identities for IPSec encap packets [ upstream commit caef2d342d226a778ad7d7bf942dfa81394bbc91 ] This was reported by Paul in [1]. After investigating the sysdump, it is clear that Hubble should not complain about such packets. [1] https://github.com/cilium/cilium/issues/15283#issuecomment-1858820397 Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
e43eeb5 hubble: Improve "stale identity observed" log context [ upstream commit 8c2dfdaeb605d1f6415adda3fe7c08b137d22bc6 ] This commit changes the log fields for the "stale identity observed" message to include the full context (i.e. trace observation point, source and destination addresses etc) for identifying which flow caused the message to be emitted. In addition, the "old" and "new" identity field names are replaced with the better fitting "userspace" and "datapath" terminology. Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
cace123 preflight: fix overriding node name env variable [ upstream commit 23ef3c0190f3da4f151398749b66a36ae76384ea ] Cilium-agent is overriding K8S_NODE_NAME env variable based on node name. Cilium-preflight was not overriding it so in case that hostname did not match node name, preflight was stuck waiting for node information. Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
6fb56f1 resource: Fix flaky TestResource_RepeatedDelete [ upstream commit 50e9666f209bafbe7110f4419512a5365e6df2d6 ] [ backporter's note: Needed to import cache package to fix compilation error. ] The fake K8s client checks if the events channel becomes full and panics if it does. Fix this by using a hand-rolled ListerWatcher to have full control over the events channel. Fixes: #28575 Fixes: a7f1eeffc1c6 ("resource: Fix double upserts on subscribe and retrying of delete events") Signed-off-by: Jussi Maki <jussi@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com> 12 January 2024, 11:08:25 UTC
0793100 bgpv1: set running flag in manager [ upstream commit 1571cce6d856d7590ecd0fc7dc7146f9c89e7035 ] BGP Manager to unset running flag when Stop is called. This is to fix flaky tests where reconcile gets called after Stop, which recreates BGP servers at shutdown stage. Signed-off-by: harsimran pabla <hpabla@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
e3acc0d hive: Unify parsing of string slices [ upstream commit 0bf036effa18390c96c188be00e19cdd923050e4 ] Hive uses pflag and viper to parse configuration flags from multiple sources. If a flag is set via command-line then the pflag parser is invoked to get to the destination type as defined in the FlagSet ("flags.StringSlice" [1]), however if the flag comes from environment or config-map, then the parsing was done by a mapstructure hook [2]. This is all well and good as long as these two ways of parsing into say []string are aligned with each other. And they were. Unfortunately these were not aligned with the pre-Hive way of parsing which used viper.GetStringSlice and similar methods. Specifically viper.GetStringSlice is implemented ([3]) via cast.ToStringSlice, which uses strings.Fields that splits by whitespace instead of by commas. So to summarize the different ways a StringSlice can be parsed: - [1]: flags.StringSlice: parses with csv.Reader (split by comma) - [2]: stringToSliceHookFunc: splits by comma - [3]: viper.GetStringSlice: splits by whitespaces So while arguably the first two are more consistent, we can't just flip from splitting by spaces to splitting by commas as that creates a huge foot-gun when fields are moved from option.Config to individual hive.Config structs. To solve this we allow splitting both ways by using two mapstructure hooks that process the values before they're pushed to the config struct: - mapstructure.StringToSliceHookFunc(",") splits first string by commas. This only impacts input coming from environment, configmap or flags.String and going to []string. - fixupStringSliceHookFunc takes []string coming from flags.StringSlice or from the StringToSliceHookFunc and resplits it by whitespace if it was of length 1. With this, we have unified the parsing of []string across all the config input methods: "foo,bar,baz" => []string{"foo", "bar", "baz"} "foo bar baz" => []string{"foo", "bar", "baz"} "foo bar,baz" => []string{"foo bar", "baz"} [1]: https://github.com/spf13/pflag/blob/master/string_slice.go#L27 [2]: https://github.com/mitchellh/mapstructure/blob/main/decode_hooks.go#L104 [3]: https://github.com/spf13/viper/blob/9154b900c34ad9d88897f7e5288ce43f457f698b/viper.go#L1067 Fixes: #29210 Fixes: b407ffce15 ("hive: Reimplement on top of dig") Signed-off-by: Jussi Maki <jussi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
1f36231 docs: Fix keyid derivation in IPsec docs [ upstream commit b26d9be1738c200274d0fb94b69ba2da03d024f0 ] Previously, when determing a keyid before the rotation, the doc suggested to run "cut -c 1". This returns only the first digit (e.g., if keyid is "15", then "1" is returned). This breaks the rotation 15=>1. Fixes: 42ef7f3f814 ("docs: Update IPsec key rotation command") Reported-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
c0dcd14 helm: enforce routing-mode when {gke,aksbyocni}.enabled is set. [ upstream commit babba798d3d01004934d95bcb43799237d244828 ] Historically, the Cilium helm chart allowed to override the routing mode leveraged in combination with {gke,aksbyocni}.enabled. This is no longer possible since aff16b2e404d ("Change routing-mode and tunnel interaction."). According to the Cilium documentation [1,2], this appears to be the correct behavior, as the routing mode must be respectively set to native and tunnel in these cases. Hence, let's validate that users didn't configure a different routing mode, to avoid falling back silently, which may be confusing. [1]: https://docs.cilium.io/en/stable/network/concepts/routing/#id6 [2]: https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-cilium (AKS tab) Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
c818b4f workflows: Increase IPsec upgrade test's timeout [ upstream commit 1bf697f8f97435ecadb28f752b16b4acee883d93 ] The IPsec upgrade test started timing out from time to time on main's CI. This commit bumps the timeout a bit to avoid such failures. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
a4341bd datapath: Fix TestNodeChurnXFRMLeaks [ upstream commit a0f4a321b95ab8efe1ace82257837830347db9b5 ] This commit fixes the following issues: * Missed enablement of the churn tests in the non-subnet mode. * The subnet mode being broken when v4 and v6 enabled [1]. [1]: https://github.com/cilium/cilium/issues/27280 Fixes: 9207b7898 ("datapath: Cover subnet encryption in XFRM leak test") Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
bcf5309 datapath: Cover subnet encryption in XFRM leak test [ upstream commit 9207b7898ea23fc625a78def5066137c90f2a579 ] This commit complements 27a8fb113b ("datapath: Integration test for XFRM leaks on node churn"). In that previous commit, subnet encryption (the XFRM config used for ENI and Azure IPAM modes) was not covered. This commit covers it. There are two pre-conditions to subnet encryption: nodes must have a list of pod subnets (cf. IPv{4,6}PodSubnets) and the encryption interface must exist and have an IP address. The test configures these two preconditions before running the usual checks for XFRM config leaks. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
1c48d53 datapath: Integration test for XFRM leaks on node churn [ upstream commit 27a8fb113b72d7bd30f7f2fbf62d64bc8ea534f3 ] In the past, we had a bug where we would leak some XFRM policies when nodes were deleted. This commit adds an integration test to ensure we don't leak XFRM policies or states when nodes are created and deleted. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
6987f1d datapath: Expose loadIPSecKeys outside pkg for use in tests [ upstream commit 8b671b3a2a5d800748ba5499b71c550e78c7acad ] This is unfortunately necessary to test some IPsec effects of the node lifecycle. Exposing this function allows us to load a test IPsec key from memory instead of from a file, to prepare the state for the creation and deletion of XFRM configs. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 09 January 2024, 15:37:45 UTC
7b864b4 workflows: Bump ConformanceAKS timeout The connectivity tests are now taking longer so we need to bump the timeout for the AKS conformance job. This isn't required on main because we split the workflow in two there, separating the IPsec part of the test. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 09 January 2024, 11:47:43 UTC
bd16079 chore(deps): update dependency cilium/cilium-cli to v0.15.19 [ upstream commit 2f1b3756c8b89b86e5abba8f11d490672d03ada9 ] Signed-off-by: renovate[bot] <bot@renovateapp.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 09 January 2024, 11:47:43 UTC
483d486 ci-e2e: Do not check for missed tail calls with host-fw [ upstream commit 829736636f84481a6f903e5d67471decfc29793b ] It's a known flake / bug [1]. [1]: https://github.com/cilium/cilium/issues/28088 Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 09 January 2024, 11:47:43 UTC
3e0d38a ci/ipsec: Skip waiting for images when skipping upgrade/dowgrade [ upstream commit 6ae935476e296986bd9e8ed7d3335748a3f3f727 ] The workflow to test upgrades/downgrades with IPsec supports two cases: upgrading from the last minor version, or from the last patch release. In the case of patch releases, there are instances where we are not able to determine the latest patch releases. This is the case on the current development branch, where no patch releases have been created yet, for example. In such a case, we skip most of the steps in the job. When implementing the check on the patch release value and the bypass of the relevant steps, we omitted to skip the step where we wait for the CI images to be available, potentially causing unnecessary wait time for the job. Let's skip this step as well. Since we're at it, we can also skip the step for setting Kind parameters. Fixes: c9dedb49f5a6 ("ci/ipsec: Skip upgrade/downgrade test to patch release on main branch") Fixes: cd93d3774959 ("ci-ipsec-upgrade: Use lvh-kind") Reported-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 21 December 2023, 07:22:57 UTC
26e509a ci-e2e: Use lvh-kind in secure way [ upstream commit 654d92f29c4f47a4e98d87b14aca03166707493e ] Otherwise, an external PR can inject malicious cmds in the action. [ Backport note: Use v1.14 version of lvh-kind instead of main ] Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 21 December 2023, 07:22:57 UTC
5f72c6d ci-ipsec-upgrade: Use lvh-kind [ upstream commit cd93d3774959645dc3f12157c2544a3d9c16df57 ] Reduces the GH workflow complexity, and will allow us to reuse the workflow for non-Kind based tests. [ Backport notes: - Minor conflict: "IMAGE=quay.io/cilium/kindest-node:${k8s_version}" not present in this branch (the block is removed in this commit anyway) - Minor conflict: Keep --conn-dirsupt-dispatch-interval 0ms - Minor conflict: Remove note on the need to update cilium to cilium-dbg - Ignore the step to debug issue 26062, not present on this branch - Use v1.14 version of lvh-kind instead of main ] Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 21 December 2023, 07:22:57 UTC
359f46d ci-ipsec-e2e: Use lvh-kind [ upstream commit f8e61f3c740c4d90783cde7954487b89cee0458f ] [ Backport notes: - Minor conflict on "Setup Conn Disrupt Test"'s command: --conn-disrupt-dispatch-interval passed to cilium-cli - Minor conflict on "Perform Conn Disrupt Test"'s command: disabling node-to-node-encryption check passed to cilium-cli - Minor conflicts in conformance-ipsec-e2e.yaml: Using "cilium" instead of "cilium-dbg" - Ignore the step to debug issue 26062, not present on this branch - Use v1.14 version of lvh-kind instead of main ] Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 21 December 2023, 07:22:57 UTC
efbb016 ci-e2e: Use lvh-kind action instead of c/little-vm-helper [ upstream commit 936c8ae01f87de2d9155d80a0f1c8bce0cd48fc1 ] [ Backport notes: - Solved conflicts in conformance-e2e.yaml, because of cilium/little-vm-helper version that was upgraded on the branch - Replaced "cilium-dbg" from main to simply "cilium" - Ignored the step to debug issue 26062, not present on this branch Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 21 December 2023, 07:22:57 UTC
6cf0f39 gh/workflows: Add lvh-kind action [ upstream commit b6255d061aeea88db51b3ccc6861bfc40188825a ] The action provisions K8s cluster on LVH VM, and then exposes it to GHA runner. With this action we will be able to run kubectl / cilium / etc commands directly from GHA runner instead of SSH'ing into VM. Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 21 December 2023, 07:22:57 UTC
1d5449f kind.sh: Allow to specify apiServer addr + port [ upstream commit c9296a5b3ce477d7bcab393b844339a471e84ff7 ] This is going to be used when exposing a K8s cluster in a LVH VM to its hypervisor host ("0.0.0.0:6443"). Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 21 December 2023, 07:22:57 UTC
bec86a5 external workloads: fix node identity error [ upstream commit 7f0e3739889528eb1aecc707b4b039ae23883daa ] [ backporter's notes: reimplemented as part of the fillLocalNode() function, which has been replaced in main by the LocalNodeStore. ] During external workloads initialization, the clustermesh-apiserver allocates a new identity for the external workload, which is then propagated through etcd to the agent running on the external workload; yet, the agent eventually overrides it with the default value (1). While this appears to be harmless from a functional point of view, as the clustermesh-apiserver configures the original identity as part of the associated the CiliumNode and CiliumEndpoint resources (which are then watched by the other agents), it also triggers an error, due to the unexpected mismatch: CEW: Invalid identity 1 in ... Let's fix this by ensuring that we correctly propagate the identity assigned to the external workloads agent by the clustermesh-apiserver. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 20 December 2023, 14:38:20 UTC
e4d877d nodediscovery: Fix bug where CiliumInternalIP was flapping [ upstream commit 263e689a299688e2233e009c22a131d77a1cc89b ] [ backporter's notes: Trivial conflicts on includes. Non-trivial conflicts in the mutateNodeResource function since it was significantly refactored. Conflict resolved by moving the conflicting code before all appending to the slice of node IP addresses. slices.DeleteFunc also doesn't exist in Go 1.20 so this commit introduces it in our own slices package. ] This fixes a bug in `UpdateCiliumNodeResource` where the `CiliumInternalIP` (aka `cilium_host` IP, aka router IP) was flapping in the node manager during restoration (i.e. during cilium-agent restarts). In particular in `cluster-pool` mode, `UpdateCiliumNodeResource` is called before the `cilium_host` IP has been restored, as there are some circular dependencies: The restored IP can only be fully validated after the IPAM subsystem is ready, but that in turn can only happen if the `CiliumNode` object has been created. The `UpdateCiliumNodeResource` function however will only announce the `cilium_host` IP if it has been restored. This commit attempts to break that cycle by not overwriting any already existing `CiliumInternalIP` in the CiliumNode resource. Overall, this change is rather hacky, in particular it does not address the fact that other less crucial node information (like the health IP) also flaps. But since we want to backport this bugfix to older stable branches too, this change is intentionally kept as minimal as possible. Example node event (as observed by other nodes) before this change: ``` 2023-12-18T12:58:20.070330814Z level=debug msg="Received node update event from custom-resource" node="{\"Name\":\"kind-worker\",\"Cluster\":\"default\",\"IPAddresses\":[{\"Type\":\"InternalIP\",\"IP\":\"172.18.0.4\"},{\"Type\":\"InternalIP\",\"IP\":\"fc00:c111::4\"}],..." subsys=nodemanager 2023-12-18T12:58:20.208082226Z level=debug msg="Received node update event from custom-resource" node="{\"Name\":\"kind-worker\",\"Cluster\":\"default\",\"IPAddresses\":[{\"Type\":\"InternalIP\",\"IP\":\"172.18.0.4\"},{\"Type\":\"InternalIP\",\"IP\":\"fc00:c111::4\"},{\"Type\":\"CiliumInternalIP\",\"IP\":\"10.0.1.245\"}],..." subsys=nodemanager ``` After this change (note the `CiliumInternalIP` present in both events): ``` 2023-12-18T15:38:23.695653876Z level=debug msg="Received node update event from custom-resource" node="{\"Name\":\"kind-worker\",\"Cluster\":\"default\",\"IPAddresses\":[{\"Type\":\"CiliumInternalIP\",\"IP\":\"10.0.1.245\"},{\"Type\":\"InternalIP\",\"IP\":\"172.18.0.4\"},{\"Type\":\"InternalIP\",\"IP\":\"fc00:c111::4\"}],..." subsys=nodemanager 2023-12-18T15:38:23.838604573Z level=debug msg="Received node update event from custom-resource" node="{\"Name\":\"kind-worker\",\"Cluster\":\"default\",\"IPAddresses\":[{\"Type\":\"InternalIP\",\"IP\":\"172.18.0.4\"},{\"Type\":\"InternalIP\",\"IP\":\"fc00:c111::4\"},{\"Type\":\"CiliumInternalIP\",\"IP\":\"10.0.1.245\"}],...}" subsys=nodemanager ``` Reported-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 19 December 2023, 11:26:34 UTC
16f7227 node/manager: Improve debug logging [ upstream commit 7084c17c9241606405338f5891c1f9d9de4e2788 ] [ backporter's notes: Trivial conflicts on includes. ] This commit improves the debug logging of node update events by using the JSON representation instead of the Go syntax representation of the node. This makes it easier to parse the log message, as IP addresses are now printed as strings instead of byte arrays. Before: ``` level=debug msg="Received node update event from custom-resource: types.Node{Name:\"kind-worker\", Cluster:\"default\", IPAddresses:[]types.Address{types.Address{Type:\"InternalIP\", IP:net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xac, 0x12, 0x0, 0x3}}, types.Address{Type:\"InternalIP\", IP:net.IP{0xfc, 0x0, 0xc1, 0x11, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3}}, types.Address{Type:\"CiliumInternalIP\", IP:net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xa, 0x0, 0x0, 0xd2}}}, IPv4AllocCIDR:(*cidr.CIDR)(0xc000613180), IPv4SecondaryAllocCIDRs:[]*cidr.CIDR(nil), IPv6AllocCIDR:(*cidr.CIDR)(nil), IPv6SecondaryAllocCIDRs:[]*cidr.CIDR(nil), IPv4HealthIP:net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xa, 0x0, 0x0, 0x30}, IPv6HealthIP:net.IP(nil), IPv4IngressIP:net.IP(nil), IPv6IngressIP:net.IP(nil), ClusterID:0x0, Source:\"custom-resource\", EncryptionKey:0x0, Labels:map[string]string{\"beta.kubernetes.io/arch\":\"amd64\", \"beta.kubernetes.io/os\":\"linux\", \"kubernetes.io/arch\":\"amd64\", \"kubernetes.io/hostname\":\"kind-worker2\", \"kubernetes.io/os\":\"linux\"}, Annotations:map[string]string(nil), NodeIdentity:0x0, WireguardPubKey:\"\"}" subsys=nodemanager ``` After: ``` level=debug msg="Received node update event from custom-resource" node="{\"Name\":\"kind-worker\",\"Cluster\":\"default\",\"IPAddresses\":[{\"Type\":\"InternalIP\",\"IP\":\"172.18.0.3\"},{\"Type\":\"InternalIP\",\"IP\":\"fc00:c111::3\"},{\"Type\":\"CiliumInternalIP\",\"IP\":\"10.0.1.245\"}],\"IPv4AllocCIDR\":{\"IP\":\"10.0.1.0\",\"Mask\":\"////AA==\"},\"IPv4SecondaryAllocCIDRs\":null,\"IPv6AllocCIDR\":null,\"IPv6SecondaryAllocCIDRs\":null,\"IPv4HealthIP\":\"10.0.1.120\",\"IPv6HealthIP\":\"\",\"IPv4IngressIP\":\"\",\"IPv6IngressIP\":\"\",\"ClusterID\":0,\"Source\":\"custom-resource\",\"EncryptionKey\":0,\"Labels\":{\"beta.kubernetes.io/arch\":\"amd64\",\"beta.kubernetes.io/os\":\"linux\",\"kubernetes.io/arch\":\"amd64\",\"kubernetes.io/hostname\":\"kind-worker\",\"kubernetes.io/os\":\"linux\"},\"Annotations\":null,\"NodeIdentity\":0,\"WireguardPubKey\":\"\"}" subsys=nodemanager ``` Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 19 December 2023, 11:26:34 UTC
6f480ac k8s: Bump CRD schema version to 1.27.x Somehow we missed bumping the minor schema version release during the v1.14 dev cycle. This creates a mild danger for conflict with 1.26.x that is currently used by Cilium 1.13.x releases. Bump this up to 1.27.0 to reduce the risk of conflicting CRD schema versions between branches. Signed-off-by: Joe Stringer <joe@cilium.io> 18 December 2023, 19:02:23 UTC
237f885 ingress: fix ingress class reconciliation Currently, deleting the default IngressClass `cilium` results in a complete deletion of the shared `CiliumEnvoyConfig` in the cilium namespace if there's a shared Ingress that doesn't have an explicit IngressClassName set. This breaks all other shared Ingresses that rely on the feature that an Ingress can reference the IngressClassName `cilium` even though the actual IngressClass with that name doesn't need to exist. Therefore, this commit fixes this by updating the shared CiliumEnvoyConfig instead of deleting it. Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> 18 December 2023, 16:03:07 UTC
074eab9 log: Do not export InitializeDefaultLogger function [ upstream commit 00ab252 ] [ Backporter's notes: ignoring changes from #26327 ] The DefaultLogger variable in the logging module serves as a parent logger which all other loggers can be derived from. It is initialized using the InitializeDefaultLogger function and then adjusted on startup based on user configuration. Users should not call InitializeDefaultLogger to create a parent logger for their logger, since the logger returned by InitializeDefaultLogger will always use the hardcoded defaults. For example, the logger returned will always be of level INFO, even if a user has enabled debug logging. To make this clear, this commit renames InitializeDefaultLogger to initializeDefaultLogger to signal that it should not be used outside of the logging module. Fixes: #29215 Signed-off-by: Ryan Drew <ryan.drew@isovalent.com> 15 December 2023, 14:09:35 UTC
1e2a73f test: Remove unnecessary call to InitializeDefaultLogger in cp suite [ upstream commit: b175548 ] The function InitializeDefaultLogger creates a new logger with the default settings and returns it. This commit removes a call to this function that doesn't save the return value, essentially calling it for no reason. Signed-off-by: Ryan Drew <ryan.drew@isovalent.com> 15 December 2023, 14:09:35 UTC
b05ab83 Revert "cilium: Ensure xfrm state is initialized for route IP before publish" [ upstream commit 0d1ee392 ] This reverts commit c9ea7a52bd59c167c6e7611d4976e3c041f4e7f0. This works around a condition where restarting the agent uses a new IP for Cilium Internal IP. But, it turns out this is because of an incorrect set helm chart option in our reproducer. When configured correctly we require CiliumInternalIP to reused so this patch is not necessary. In fact it complicates the code so lets drop it. The helm option is cleanState. It must be set to false cleanState=false Note that cleanState="false" is a string type and will default to true because of bool typing. Creating a subtle and broke config. Signed-off-by: John Fastabend <john.fastabend@gmail.com> 14 December 2023, 23:57:03 UTC
053b393 ci-ipsec-upgrade: Add vxlan w/ no EP routes [ upstream commit f7894740c1bdd5ac877ad14ec0e6c1bf60687c73 ] [ backporter's notes: conflicts due to 5.10 having been disabled in 7a88c8c726065b60d1a56fb92817451a605e0d26, resolved manually. ] This is more common configuration than the existing vxlan + EP one. Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 14 December 2023, 14:54:10 UTC
2129a07 workflows: Make the conn-disrupt test more sensitive [ upstream commit 13efef3ef6606302e460d53a77324a0535a4496a ] [ backporter's notes: changes to `tests-clustermesh-upgrade.yaml` and `tests-e2e-upgrade.yaml` were ignored as they were depending on changes not backported to v1.14. ] By reducing the interval between two sent packets to 0ms, we are making the conn-disrupt test more sensitive to drops. That should help us identify remaining bugs in upgrades, key rotations, etc. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 14 December 2023, 14:54:10 UTC
bc1aafa documentation: Policy L7 section also encompasses FQDN proxy. [ upstream commit 91a5c12020d23f523bce51d96abbd440bcbf0f72 ] The metrics in Policy L7 also affect FQND Proxy, update the section header to reflect that. Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 14 December 2023, 14:54:10 UTC
188fe54 documentation: update L7 upstream reply seconds with correct labels. [ upstream commit 1747289762f28f803d80130a2d9f81896a72af66 ] Currently the labels used by this metric are missing from documentation. Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 14 December 2023, 14:54:10 UTC
2596a50 metrics: remove formerly deprecated cilium_policy_l7_* metrics. [ upstream commit c0b59557e0906f07dcf3d6b774bf4a451c3bbfe9 ] [ backporter's notes: conflicts in `upgrade.rst`, resolved manually by adding missing headers. ] These metrics have been deprecated since 2019: fddcf11d895e98b0d3b395914b4f66b97cfe4ef3. cilium_policy_l7_total is the intended replacement. Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 14 December 2023, 14:54:10 UTC
c5088e7 metrics: policy_l7_total: add "proxy_type" label. [ upstream commit 18d1bee0587748e4e25a9be9dc2ff5735a569f5f ] [ backporter's notes: conflicts in `upgrade.rst`, resolved manually by adding missing headers. ] cilium_l7_total provides counters for rates of various l7 flows in the agent. Specifically, Envoy l7 proxy and fqdn proxy. Because these have different code paths and policy types it would be useful to be able to distinguish between general l7 traffic events and FQDN. Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 14 December 2023, 14:54:10 UTC
afe175b ci: fix dns issue when pulling cilium-docker-plugin in ci-runtime [ upstream commit 83425f21b71a3d2927d86584e19879554b9abaf8 ] It seems that even though we're setting the nameserver at the top of `/etc/resolv.conf`, in some cases docker still uses 127.0.0.53 to resolve names while pulling the cilium docker plugin in the ci-runtime test. It seems as docker tries to use nameserver information from `systemd-resolved`. Therefore, this commit tries to force docker to use the nameserver 1.1.1.1, by removing the resolv.conf symlink, deleting the resolv.conf from systemd-resolved and restarting the docker service after applying the changes. Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
593e724 complexity-tests: fix copying verifier log output to artifacts [ upstream commit c947484fa7a7f4347e42a2565074a7f1ffe27d05 ] It turns out that the following find command is subtle: find . -name foo -o -name bar -exec ... This means: execute the command for bar. It doesn't execute the command for foo. For this reason verifier logs are currently not being copied correctly into GH artifacts. Fixes: 735807fb16 ("test/verifier: fix complexity tests not being recompiled") Signed-off-by: Lorenz Bauer <lmb@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
dca31fa gha: add step to ensure presence/absence of the AWS iptables chains [ upstream commit 510739146996e3fc0c2aeaba34c33fb5ade31a99 ] Recently, a regression of the poststart-eni.sh script got unnoticed, as we are not explicitly testing it as part of the E2E pipelines. Let's add a step to the Conformance EKS and Conformance AWS-CNI workflows to assert that, in the former case, the stale AWS iptables chains are removed, and in the latter they are not modified. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
66143d3 gha: enable IPv6 in clustermesh upgrade/downgrade workflow [ upstream commit dbe56dda26eb430c0af71670efc92981dfd4cd11 ] Now that known issues causing connection disruption (which appeared to mostly affect dual stack clusters) have been fixed, let's enable IPv6 again in the clustermesh upgrade/downgrade workflow. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
8edebce install: fix stale aws iptables chains deletion [ upstream commit 854ea3d2ad5fda0ca8171c330d08337481ee3a52 ] The poststart-eni.sh script got recently modified to delete both AWS-SNAT and AWS-CONNMARK related chains. Yet, the filter is now a regular expression, and does not return any match with plain grep. Let's fix this by setting the `-E` (--extended-regexp) flag. Fixes: b836cb1209a8 ("helm: Add missing type to poststart iptables regex") Fixes: 8c86d079949b ("install: Remove AWS-CONNMARK-CHAIN iptables") Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
041490f pkg/metrics: remove old todo. [ upstream commit 83b87c4881b60bf8ba28fac8f894605ebcb1ceca ] This comment is over 5 years old and no longer seems relevant. Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
e0c33e4 metrics: fix issue where logging err/warn metric is never updated. [ upstream commit 7e13f1a8288f93402c60ff972b82a84bbf06b147 ] [ backporter's notes: dropped the Registry parameter from the new invoke function in pkg/metrics/cell.go, as it is not provided. ] Because legacy metrics are now initialized in Hive, the logging hook was being set to the NoOpCounterVec instance. This moves initializing the errors/warnings metric out of the NewLegacyMetrics function and provides a manual way to init metrics that must be initialized prior to Hive. Fixes: #29525 Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
cdbf61b ci: always use full matrix for scheduled cloud-provider workflows [ upstream commit 1f1c3840be09a54e84e08320611c8b72994410ba ] Cloud provider related workflows use the full configuration as matrix when being executed on a scheduled basis on stable branches, whereas only the default configuration is used on PR workflows. Currently, this decision checks whether the workflow is triggered via `event_name == schedule`. This is working fine on `main`, but not on all other stable branches where the workflows are triggered via workflow_dispatch event (called by a scheduled workflow (ariane-scheduled.yaml) on main). Therefore, this commit extends the decision to check for the input `PR-number` starting with a "v". This is the case for Ariane triggered runs - as they pass the branch name as PR-number (PR runs pass the actual numeric PR number). Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
61820d5 ci: remove LVH GH action property dns-resolver [ upstream commit a2694fc18d0ba027dfb5241e00d3658380d9ac35 ] [ backporter's notes: skipped changes in tests-e2e-upgrade.yaml, as not present in v1.14. ] The property dns-resolver has been removed from the little-vm-helper GitHub action. Therefore, this commit removes the usage of it in the cilium repository. See: https://github.com/cilium/little-vm-helper/pull/118 Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
7f29b80 ci: add nameserver 1.1.1.1 to conformance-runtime test LVM [ upstream commit 1c10df2f535ab83d61d9d65225a5296e143dcb3e ] With the removal of setting a nameserver via the little-vm-helper GitHub action, conformance-runtime tests are failing quite often with the following error. ``` dial tcp: lookup quay.io on 127.0.0.53:53: read udp 127.0.0.1:40553->127.0.0.53:53: read: connection refused ``` The assumption is that the local DNS resolver isn't ready at that time when pulling the image. Therefore, this way temporarily re-adds the nameserver `1.1.1.1` manually. See: https://github.com/cilium/little-vm-helper/pull/118 Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
41c4371 hubble: Reduce "stale identity observed" warnings [ upstream commit 28975e360f2031e99788e365cc806079886c200a ] [ backporter's notes: introduced a simplified version of the 'identity.IsWorld()' method, which was not present in v1.14, as added in a94fa56f6713 ("Fix CIDR to World Entity Conversion Bug"). ] In Hubble, ignore certain cases where the datapath security ID does not match the userspace security ID. Signed-off-by: Lucas Leblow <lucasleblow@mailbox.org> Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 14 December 2023, 12:47:09 UTC
6896a4f ci: In conn-disrupt-test action, disable node-to-node-encryption check The node-to-node-encryption test is known to fail often on branches v1.13 and v1.14 with jobs running on kernels 5.4 and 5.10, and so far we haven't been able to figure out why. The test brings little value anyway, so we disable it on the branches. Link: https://github.com/cilium/cilium/issues/29351 Signed-off-by: Quentin Monnet <quentin@isovalent.com> 14 December 2023, 11:23:52 UTC
754a885 Revert "ci-ipsec-upgrade: Disable Linux 5.10-based configs" This reverts commit 7a88c8c726065b60d1a56fb92817451a605e0d26. Disabling the job on kernel 5.10 was not enough to address the issue we've been observing in CI: it also hits 5.4. Let's revert this change; instead we'll disable the faulty test in a separate commit. Signed-off-by: Quentin Monnet <quentin@isovalent.com> 14 December 2023, 11:23:52 UTC
77f0d11 chore(deps): update all github action dependencies to v5 Signed-off-by: renovate[bot] <bot@renovateapp.com> 12 December 2023, 16:49:55 UTC
e0152fd chore(deps): update github/codeql-action action to v2.22.9 Signed-off-by: renovate[bot] <bot@renovateapp.com> 12 December 2023, 16:27:30 UTC
64423a5 install: Update image digests for v1.14.5 Generated from https://github.com/cilium/cilium/actions/runs/7170425815. `docker.io/cilium/cilium:v1.14.5@sha256:d3b287029755b6a47dee01420e2ea469469f1b174a2089c10af7e5e9289ef05b` `quay.io/cilium/cilium:v1.14.5@sha256:d3b287029755b6a47dee01420e2ea469469f1b174a2089c10af7e5e9289ef05b` `docker.io/cilium/cilium:stable@sha256:d3b287029755b6a47dee01420e2ea469469f1b174a2089c10af7e5e9289ef05b` `quay.io/cilium/cilium:stable@sha256:d3b287029755b6a47dee01420e2ea469469f1b174a2089c10af7e5e9289ef05b` `docker.io/cilium/clustermesh-apiserver:v1.14.5@sha256:7eaa35cf5452c43b1f7d0cde0d707823ae7e49965bcb54c053e31ea4e04c3d96` `quay.io/cilium/clustermesh-apiserver:v1.14.5@sha256:7eaa35cf5452c43b1f7d0cde0d707823ae7e49965bcb54c053e31ea4e04c3d96` `docker.io/cilium/clustermesh-apiserver:stable@sha256:7eaa35cf5452c43b1f7d0cde0d707823ae7e49965bcb54c053e31ea4e04c3d96` `quay.io/cilium/clustermesh-apiserver:stable@sha256:7eaa35cf5452c43b1f7d0cde0d707823ae7e49965bcb54c053e31ea4e04c3d96` `docker.io/cilium/docker-plugin:v1.14.5@sha256:45c59f853c22997f811a35b01b2a6520d9d6d537c99a54267f0a70b64bd8ea9c` `quay.io/cilium/docker-plugin:v1.14.5@sha256:45c59f853c22997f811a35b01b2a6520d9d6d537c99a54267f0a70b64bd8ea9c` `docker.io/cilium/docker-plugin:stable@sha256:45c59f853c22997f811a35b01b2a6520d9d6d537c99a54267f0a70b64bd8ea9c` `quay.io/cilium/docker-plugin:stable@sha256:45c59f853c22997f811a35b01b2a6520d9d6d537c99a54267f0a70b64bd8ea9c` `docker.io/cilium/hubble-relay:v1.14.5@sha256:dbef89f924a927043d02b40c18e417c1ea0e8f58b44523b80fef7e3652db24d4` `quay.io/cilium/hubble-relay:v1.14.5@sha256:dbef89f924a927043d02b40c18e417c1ea0e8f58b44523b80fef7e3652db24d4` `docker.io/cilium/hubble-relay:stable@sha256:dbef89f924a927043d02b40c18e417c1ea0e8f58b44523b80fef7e3652db24d4` `quay.io/cilium/hubble-relay:stable@sha256:dbef89f924a927043d02b40c18e417c1ea0e8f58b44523b80fef7e3652db24d4` `docker.io/cilium/kvstoremesh:v1.14.5@sha256:d7137edd0efa2b1407b20088af3980a9993bb616d85bf9b55ea2891d1b99023a` `quay.io/cilium/kvstoremesh:v1.14.5@sha256:d7137edd0efa2b1407b20088af3980a9993bb616d85bf9b55ea2891d1b99023a` `docker.io/cilium/kvstoremesh:stable@sha256:d7137edd0efa2b1407b20088af3980a9993bb616d85bf9b55ea2891d1b99023a` `quay.io/cilium/kvstoremesh:stable@sha256:d7137edd0efa2b1407b20088af3980a9993bb616d85bf9b55ea2891d1b99023a` `docker.io/cilium/operator-alibabacloud:v1.14.5@sha256:e0152c498ba73c56a82eee2a706c8f400e9a6999c665af31a935bdf08e659bc3` `quay.io/cilium/operator-alibabacloud:v1.14.5@sha256:e0152c498ba73c56a82eee2a706c8f400e9a6999c665af31a935bdf08e659bc3` `docker.io/cilium/operator-alibabacloud:stable@sha256:e0152c498ba73c56a82eee2a706c8f400e9a6999c665af31a935bdf08e659bc3` `quay.io/cilium/operator-alibabacloud:stable@sha256:e0152c498ba73c56a82eee2a706c8f400e9a6999c665af31a935bdf08e659bc3` `docker.io/cilium/operator-aws:v1.14.5@sha256:785ccf1267d0ed3ba9e4bd8166577cb4f9e4ce996af26b27c9d5c554a0d5b09a` `quay.io/cilium/operator-aws:v1.14.5@sha256:785ccf1267d0ed3ba9e4bd8166577cb4f9e4ce996af26b27c9d5c554a0d5b09a` `docker.io/cilium/operator-aws:stable@sha256:785ccf1267d0ed3ba9e4bd8166577cb4f9e4ce996af26b27c9d5c554a0d5b09a` `quay.io/cilium/operator-aws:stable@sha256:785ccf1267d0ed3ba9e4bd8166577cb4f9e4ce996af26b27c9d5c554a0d5b09a` `docker.io/cilium/operator-azure:v1.14.5@sha256:9203f5583aa34e716d7a6588ebd144e43ce3b77873f578fc12b2679e33591353` `quay.io/cilium/operator-azure:v1.14.5@sha256:9203f5583aa34e716d7a6588ebd144e43ce3b77873f578fc12b2679e33591353` `docker.io/cilium/operator-azure:stable@sha256:9203f5583aa34e716d7a6588ebd144e43ce3b77873f578fc12b2679e33591353` `quay.io/cilium/operator-azure:stable@sha256:9203f5583aa34e716d7a6588ebd144e43ce3b77873f578fc12b2679e33591353` `docker.io/cilium/operator-generic:v1.14.5@sha256:303f9076bdc73b3fc32aaedee64a14f6f44c8bb08ee9e3956d443021103ebe7a` `quay.io/cilium/operator-generic:v1.14.5@sha256:303f9076bdc73b3fc32aaedee64a14f6f44c8bb08ee9e3956d443021103ebe7a` `docker.io/cilium/operator-generic:stable@sha256:303f9076bdc73b3fc32aaedee64a14f6f44c8bb08ee9e3956d443021103ebe7a` `quay.io/cilium/operator-generic:stable@sha256:303f9076bdc73b3fc32aaedee64a14f6f44c8bb08ee9e3956d443021103ebe7a` `docker.io/cilium/operator:v1.14.5@sha256:234c177b6f4261405d9dfa2c50ce253bee1edd8147cfba0adbc22a57235d3b68` `quay.io/cilium/operator:v1.14.5@sha256:234c177b6f4261405d9dfa2c50ce253bee1edd8147cfba0adbc22a57235d3b68` `docker.io/cilium/operator:stable@sha256:234c177b6f4261405d9dfa2c50ce253bee1edd8147cfba0adbc22a57235d3b68` `quay.io/cilium/operator:stable@sha256:234c177b6f4261405d9dfa2c50ce253bee1edd8147cfba0adbc22a57235d3b68` Signed-off-by: Maciej Kwiek <maciej@isovalent.com> 12 December 2023, 11:59:07 UTC
46e3b70 chore(deps): update all lvh-images main Signed-off-by: renovate[bot] <bot@renovateapp.com> 12 December 2023, 09:35:10 UTC
85db28b Prepare for release v1.14.5 Signed-off-by: Maciej Kwiek <maciej@isovalent.com> 11 December 2023, 14:09:20 UTC
06a9f14 bpf: Fix identity determination in bpf_overlay.c [ upstream commit 895630ba293dc0e40197bbc23ce188ba1557f27f ] When DSR with Geneve is enabled, Cilium identity is not determined by the client's IP address and requests from outside cluster are dropped even though they are permitted by CiliumNetworkPolicy using `fromCIDR`. This commit inputs identity that is from the client IP address. Fixes: #29153 Signed-off-by: Tomoki Sugiura <tomoki-sugiura@cybozu.co.jp> 11 December 2023, 09:57:44 UTC
4582a9d bpf: dsr: merge Ingress tail-calls into nodeport_lb*() [ upstream commit c00d31305c1911cf20e6c1a0e3db1b297c1d3dfe ] The DSR Ingress path was initially implemented through a tail-call for program size reasons. But with the recent improvements to the CT handling, we have sufficient program space to run the DSR ingress handling straight from nodeport_lb*(). This reduces duplicated code (eg. extracting the CT tuple and DSR info twice), avoids additional error handling, and simplifies the overall code flow. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> 11 December 2023, 09:57:44 UTC
462a72b bpf: ct: remove unused ct_action parameter [ upstream commit 07c05fe5eaeb8146bae914ef07f4f583b598f145 ] __ct_lookup*() now selects this value internally, and the caller's parameter is ignored. Remove all the calling logic that determined the ct_action and plumbed it into the CT lookup. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> 11 December 2023, 09:57:44 UTC
36e496f bpf: ct: simplify ct_action parameter for CT lookup [ upstream commit 5c39551e987513acc4d8cf747d2d96a4bcbd7942 ] For a CT lookup, the calling paths currently need to determine a `ct_action` parameter. This is typically ACTION_CREATE (for TCP/UDP/SCTP), or ACTION_UNSPEC for most types of ICMP traffic. But ever since fd5ea2a3d213 ("bpf: Don't reset TCP timer on final ACK"), __ct_lookup() will only apply ACTION_CREATE handling to TCP packets with the SYN flag set. Otherwise it has the same effect as ACTION_UNSPEC. Simplify the logic by ignoring the passed-in value, and manually selecting ACTION_CREATE for applicable traffic in the CT lookup helpers (same as we already do for ACTION_CLOSE). A subsequent patch will remove all the unused code that passed the ct_action around. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> 11 December 2023, 09:57:44 UTC
2095837 bpf: ct: clean up tuple-swap helpers [ upstream commit d5ee4e70cfa5ea6941633d1cce545a541875b964 ] We're still using all variants of the tuple-swap helpers in some parts of the code base. But let's at least re-use the intermediate helpers to compose the bigger ones. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> 11 December 2023, 09:57:44 UTC
back to top