Skip to main content

Browse the archive

https://github.com/cilium/cilium
12 July 2024, 03:14:21 UTC
sort by:
Revision Author Date Message Commit Date
4ceb82a Maciej Kwiek 11 December 2023, 14:00:00 UTC Prepare for release v1.12.17 Co-authored-by: Andrew Sauber <2046750+asauber@users.noreply.github.com> Signed-off-by: Maciej Kwiek <maciej@isovalent.com> 11 December 2023, 22:20:59 UTC
0186818 Andrew Sauber 11 December 2023, 18:48:48 UTC travis: install buildkit in pre-install Signed-off-by: Andrew Sauber <2046750+asauber@users.noreply.github.com> 11 December 2023, 22:20:59 UTC
fffa54e Julian Wiedmann 05 November 2023, 09:24:31 UTC ctmap: consider CT entry's .dsr flag in PurgeOrphanNATEntries() [ upstream commit dfbae95eb544fc218a9cb251edd281afac6a96c2 ] [ backporter's notes: also bring back isDsrEntry() ] The BPF datapath potentially re-creates a CT entry, in particular when a DSR connection gets re-opened as local connection. Such a re-purposed CT entry then leaves a DSR NAT entry behind. Currently we wouldn't clean up such NAT entries (as the matching CT entry still exists). But once we look at the CT entry's .dsr flag, we understand that the CT entry is actually no longer a match for the NAT entry. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 11 December 2023, 09:58:02 UTC
7fc9ee2 Julian Wiedmann 30 October 2023, 03:34:56 UTC ctmap: set `dsr` flag for relevant CT entries in TestOrphanNatGC() [ upstream commit 74b3f56af06823a0c0c3716731e72090df172cc1 ] CT entries that get created for a DSR connection by the datapath will have the `dsr` flag set. Reflect this in the CT entries that we use for tests. The flag currently doesn't make a difference for the GC logic, but let's still be a bit more accurate. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 11 December 2023, 09:58:02 UTC
78b2638 renovate[bot] 08 December 2023, 16:52:20 UTC chore(deps): update hubble cli to v0.12.3 Signed-off-by: renovate[bot] <bot@renovateapp.com> 08 December 2023, 22:39:51 UTC
ad1a8aa Cilium Imagebot 08 December 2023, 15:03:17 UTC images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> 08 December 2023, 19:13:35 UTC
482f492 Casey Callendrello 05 December 2023, 10:11:12 UTC images: bump cni plugins to v1.4.0 [ upstream commit 1248536a55b692ada3749da08e52afc91e10b2b2 ] The result of running ``` images/scripts/update-cni-version.sh 1.4.0 ``` Signed-off-by: Casey Callendrello <cdc@isovalent.com> 08 December 2023, 19:13:35 UTC
e9acb55 Cilium Imagebot 06 December 2023, 13:44:08 UTC images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> 08 December 2023, 14:58:55 UTC
2a553f7 renovate[bot] 06 December 2023, 12:37:24 UTC chore(deps): update docker.io/library/golang docker tag to v1.20.12 Signed-off-by: renovate[bot] <bot@renovateapp.com> 08 December 2023, 14:58:55 UTC
641c175 Robin Hahling 06 December 2023, 15:14:43 UTC vendor: update logrus v1.9.0 => v1.9.3 Release v1.9.3 address a potential DoS vulnerability. Signed-off-by: Robin Hahling <robin.hahling@gw-computing.net> 08 December 2023, 14:22:08 UTC
6654492 André Martins 22 November 2023, 23:01:49 UTC images/cilium: copy the cilium-envoy binary into Cilium image [ upstream commit 807e494b8e689c05c6103cd1e438e305ee847fbe ] When we integrated cilium-envoy into Cilium's image we have made the assumption that the image only contained the cilium-envoy binary, which made it safe to copy the entire image into Cilium's. However, since 3698c40e878c, the cilium-envoy's base image was switched to Ubuntu's instead of "scratch". This had the consequence of overwriting the files of Cilium's Runtime image with Cilium-envoy's base image. To fix this, we should only copy the cilium-envoy binary available on the cilium-envoy image. Fixes: 3698c40e878c ("cilium/proxy: updating proxy image to latest version") Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Tam Mach <tam.mach@cilium.io> 08 December 2023, 08:45:00 UTC
fb7097a Andrii Iuspin 05 December 2023, 17:32:32 UTC helm: add resources via initResources for the agent init containers [ upstream commit de788fa9be616383c0146cd7282db032408f1b6b ] Signed-off-by: Andrii Iuspin <yuspin@gmail.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> Signed-off-by: Tam Mach <tam.mach@cilium.io> 08 December 2023, 07:59:30 UTC
263a2c0 Andrii Iuspin 30 November 2023, 14:56:48 UTC helm: Add extraVolumes and extraVolumeMounts to hubble-relay [ upstream commit 76126b7ef3024ae6589fe38ddd2c49df056ef8eb ] Signed-off-by: Andrii Iuspin <yuspin@gmail.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> 08 December 2023, 07:59:30 UTC
a352c47 Andrii Iuspin 30 November 2023, 14:14:53 UTC helm: Add extraVolumeMounts to etcd-init and etcd [ upstream commit 22a4d1d6c1d173831bfadc946b5f3b063d4af648 ] Signed-off-by: Andrii Iuspin <yuspin@gmail.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> 08 December 2023, 07:59:30 UTC
113a96d Andrii Iuspin 30 November 2023, 14:00:59 UTC helm: Add automount related fields to preflight [ upstream commit 6f544480504b77afd8e5b852d64e25ac500b4f5e ] This commit is to add automountServiceAccountToken, extraVolumes and extraVolumeMounts field to preflight workload. Signed-off-by: Andrii Iuspin <yuspin@gmail.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> 08 December 2023, 07:59:30 UTC
9b3cc45 Andrii Iuspin 29 November 2023, 21:49:48 UTC helm: Add extraVolumeMounts to cilium-monitor and clean-cilium-state [ upstream commit 4a5cbba14aa51e1c5ae83feb4d8771b20b1e5dd1 ] Signed-off-by: Andrii Iuspin <yuspin@gmail.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> 08 December 2023, 07:59:30 UTC
fb56b84 darox 12 April 2023, 11:21:11 UTC Add SA and extravolume to nodeinit ds [ upstream commit e771a9cc1032bf88fe7ce9bdaa65b606fe9548ac ] This commit is to make sure that users can enable/disable SA token auto mount, which is recommended in NSA security hardening guide. This PR is for the cilium-nodeinit daemonset. https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF Signed-off-by: darox <maderdario@gmail.com> Signed-off-by: Tam Mach <tam.mach@cilium.io> 08 December 2023, 07:59:30 UTC
c0d2681 Marco Iorio 07 December 2023, 08:44:50 UTC gha: align ci-ipsec-e2e workflow name to main Otherwise the name of the workflow displayed by GitHub bounces depending on which one is executed last. This specific change seems to have been lost while backporting e9e43fe3f8c7 ("ci: rename name fields"). Fixes: bdb02d4281d9 ("ci: rename name fields") Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> 07 December 2023, 13:16:36 UTC
0e8c53f Tam Mach 06 December 2023, 11:02:34 UTC envoy: Bump cilium-envoy with golang 1.21.5 This is mainly for recently golang version v1.21.5 Relates build: https://github.com/cilium/proxy/actions/runs/7113088396/job/19364351580 Signed-off-by: Tam Mach <tam.mach@cilium.io> 06 December 2023, 21:33:39 UTC
46d5b5a Chris Tarazi 02 December 2023, 07:30:43 UTC health/server: Fix stale references to old nodes during health probe [ upstream commit 7c7b72393c8afd7595f976db2ba64ef9227c0c1b ] Given the order of operations in prober.OnIdle, it is possible for the health probe to have a stale references to a deleted nodes. When that occurs, node connectivity metrics which were previously deleted [1] would be brought back, causing confusion. If users defined alerts for node connectivity health checks metrics (see example below), then this would erroneously trigger because the old nodes would appear in the metric labels as a failing health check. Example given deletion of "kind-worker2" node: ``` cilium_node_connectivity_status source_cluster="kind-kind" source_node_name="kind-worker" target_cluster="kind-kind" target_node_name="kind-control-plane" target_nod e_type="remote_intra_cluster" type="endpoint" 1.000000 cilium_node_connectivity_status source_cluster="kind-kind" source_node_name="kind-worker" target_cluster="kind-kind" target_node_name="kind-control-plane" target_nod e_type="remote_intra_cluster" type="node" 1.000000 cilium_node_connectivity_status source_cluster="kind-kind" source_node_name="kind-worker" target_cluster="kind-kind" target_node_name="kind-worker" target_node_type= "local_node" type="endpoint" 1.000000 cilium_node_connectivity_status source_cluster="kind-kind" source_node_name="kind-worker" target_cluster="kind-kind" target_node_name="kind-worker" target_node_type= "local_node" type="node" 1.000000 cilium_node_connectivity_status source_cluster="kind-kind" source_node_name="kind-worker" target_cluster="kind-kind" target_node_name="kind-worker2" target_node_type ="remote_intra_cluster" type="endpoint" 0.000000 ``` Fixes: d9e1ff897d ("cilium-health: Remove unnecessary goroutine") [1]: e9f97cd0e3 ("Ensures prometheus metrics associated with a deleted node are no longer reported.") Signed-off-by: Chris Tarazi <chris@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 06 December 2023, 17:15:51 UTC
ac0e18c Chris Tarazi 02 December 2023, 07:29:23 UTC node/manager: Add info logs for added and deleted nodes [ upstream commit 4787f8ee43249085a02592ed82d3396eaf09eebb ] [ backporter's notes: had to resolve rename conflicts. ] Similar to how useful log msgs are when endpoints created and deleted, this log is useful for understanding when nodes are added and deleted in production clusters. Signed-off-by: Chris Tarazi <chris@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 06 December 2023, 17:15:51 UTC
3876191 viktor-kurchenko 29 November 2023, 16:17:54 UTC CountUniqueIPsecKeys function returns error to allow consumers to implement error handling. [ upstream commit 6f227fbd59450d9aefa3fd1f95c6f76640dc1245 ] [ backporter's notes: conflicts due to `cilium/cmd` having been renamed to `cilium-dbg/cmd`. ] Signed-off-by: viktor-kurchenko <viktor.kurchenko@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 06 December 2023, 17:15:51 UTC
a9ca54e viktor-kurchenko 15 November 2023, 09:59:33 UTC cmd: Handle non-AEAD IPsec keys in encrypt status [ upstream commit da354d96b40e1030f1f62ca69587a8f12c34917f ] CountUniqueIPsecKeys function fixed to count non-Aead keys and catch unsupported XfrmStateAlgo combinations. Fixes cilium#29181. Signed-off-by: viktor-kurchenko <viktor.kurchenko@isovalent.com> Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com> 06 December 2023, 17:15:51 UTC
be374aa Marco Hofstetter 05 December 2023, 07:56:33 UTC guestbook: update example & test with leader/follower naming The guestbook in version v5 fails trying to connect to `redis-leader`. The reason is that the deployment is still named `redis-master`. Therefore, this commit renames the example & test guestbook deployments to use the leader/follower naming. Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> 05 December 2023, 14:02:55 UTC
888779d Marco Hofstetter 04 December 2023, 13:18:20 UTC examples: update guestbook example with new image registry The GCP Kubernetes Engine Samples migrated their image registry from Google Container Registry to Google Artifact Registry. Hence, the image gb-frontend from the guestbook example is no longer available. Therefore, this commit changes the example to use the new registry. Issue: GoogleCloudPlatform/kubernetes-engine-samples#209 Guestbook PR: GoogleCloudPlatform/kubernetes-engine-samples#194 Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> 05 December 2023, 14:02:55 UTC
c1ea85b Marco Hofstetter 04 December 2023, 13:22:33 UTC ci: remove empty github workflow file tests-nightly.yaml This commit removes the empty workflow file `tests-nightly.yaml`. This prevents the workflow from failing. Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com> 04 December 2023, 20:20:21 UTC
3cb86ef Paul Chaignon 21 November 2023, 19:09:59 UTC workflows: Add debug info to IPsec key rotation test [ upstream commit a6e22ba7c4e8e25a50f36b35361b49f38c27776f ] To detect that the key rotation began or that it successfully ended, we rely on the number of keys in use reported by `cilium-dbg encrypt status`. When either of those steps times out, it would be good to have information on what the number of keys was. This commit adds that debug information to the test. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 01 December 2023, 12:21:52 UTC
eb17c7b Marco Iorio 27 November 2023, 15:29:23 UTC gha: wait for downgrade images to be ready in clustermesh upgrade test [ upstream commit a587b8837be1b6d67021593cb13fa6bdd783ec0a ] Currently, we only wait for the images from the current PR/main to be available in the clustermesh upgrade tests. Yet, it can happen that the ones from the stable branch are not available (either because they are being built, or something went wrong), leading to confusing failures (as the installation eventually fails due to ImagePullBackOff errors). To prevent this, let's add an explicit step to additionally wait for downgrade images to be available before proceeding with the installation step, so that also the error message is clear. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 01 December 2023, 12:21:52 UTC
1d82aa5 Paul Chaignon 22 November 2023, 19:45:22 UTC ipsec: Merge functions ipSecJoinState and ipSecNewState [ upstream commit ba3fa898ee40ab5a581a27c5f2c0dad2f1876286 ] ipSecJoinState is never called without ipSecNewState and vice versa. So let's just merge both to have all XFRM state initialization in the same place. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 01 December 2023, 12:21:52 UTC
37d892b Paul Chaignon 22 November 2023, 19:30:26 UTC ipsec: Move SPI parsing to own function and test it [ upstream commit f7a58affe5597bd6299a92aa48e9f4a86aa87cf7 ] The SPI parsing logic is fairly complex so let's move it to its own function and write a unit test for that. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 01 December 2023, 12:21:52 UTC
9c527b3 Julian Wiedmann 16 July 2023, 14:39:24 UTC bpf: nat: only set SNAT_DONE when packet was actually SNATed [ upstream commit 2393707606c409351118fda59207de3131375730 ] With eff26cf680e5 ("datapath: Fix double SNAT") the outbound SNAT path now sets ctx_snat_done_set() after checking whether a packet requires SNAT. This was meant to avoid double-NATing when a packet passes through multiple network interfaces with a to-netdev program. But looking at the SNAT code in detail, some of its conditions only apply on specific interfaces (see nodeport_has_nat_conflict_ipv4(), which checks for `NATIVE_DEV_IFINDEX == DIRECT_ROUTING_DEV_IFINDEX`). So if a packet passes through multiple interfaces which all have `to-netdev` attached, the first `to-netdev` program might set SNAT_DONE even when some subsequent program (attached to DIRECT_ROUTING_DEV_IFINDEX) would still want to apply SNAT to the packet. Therefore we should apply the SNAT checks on *each* interface, until we have actually SNATed the packet. Only then set the SNAT_DONE marker. Note that this also fixes an EgressGW bug in nodeport_snat_fwd_ipv4(), where we would redirect the packet even if snat_v4_nat() reported an error. Fixes: eff26cf680e5 ("datapath: Fix double SNAT") Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Jussi Maki <jussi@isovalent.com> 01 December 2023, 12:21:52 UTC
a40e6fc Casey Callendrello 22 June 2023, 09:54:48 UTC endpoint: add policy engine race test [ upstream commit 8e163a9b70d9b5e09516828831a5378f0bed79bf ] This adds a small test that ensures incremental updates are never lost, even in the face of significant identity churn. It simulates a churning ipcache flinging identities in to the policy engine, and similarly recalculates policy constantly. Signed-off-by: Casey Callendrello <cdc@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 29 November 2023, 23:42:05 UTC
6d479af Casey Callendrello 22 June 2023, 09:53:40 UTC test/MockIdentityAllocator: Sanitize the generated ID [ upstream commit 9623641f6092f28e7f6974864194b146a0cdc187 ] This ensures the generated ID works like IDs allocated normally - that their LabelArray is set. Signed-off-by: Casey Callendrello <cdc@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 29 November 2023, 23:42:05 UTC
6aa6a1e Casey Callendrello 02 June 2023, 13:44:57 UTC endpoint: don't hold the endpoint lock while generating policy [ upstream commit f048a6a88b7bbffb1295358cfbc3c9a7bfbf4ff1 ] As preparation for other refactors of the policy engine, no longer hold the endpoint lock while calculating policy. This is safe to do, since the only input is the endpoint's security identity. Furthermore, if, somehow, policy were to be calculated in parallel, we can reject an update if its revision is too old. Signed-off-by: Casey Callendrello <cdc@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 29 November 2023, 23:42:05 UTC
aa8d4aa Casey Callendrello 05 June 2023, 12:26:57 UTC pkg/proxy: mechanical: remove unused methods from interface [ upstream commit b63115b4c80a5014a8de93a107b19af0b90837e2 ] These methods are no longer used; remove them from the EndpointInfoSource interface. Signed-off-by: Casey Callendrello <cdc@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 29 November 2023, 23:42:05 UTC
9142a65 Casey Callendrello 05 June 2023, 12:17:47 UTC pkg/endpoint: make some more accessor methods lock-free [ upstream commit e20b16d70843530aefad9ac8c3ae0834c7b6b057 ] [ backporter's notes: 1. manager_test: we don't yet have ipcache test infra structure, use the real thing instead (as other tests do) 2. go1.18 compat: atomic.Pointer -> atomic.Value ] It turns out that most of the endpoint identities, e.g. pod name / namespace, are actually immutable. So, there's no need to grab a lock before reading them. Signed-off-by: Casey Callendrello <cdc@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 29 November 2023, 23:42:05 UTC
401025e Casey Callendrello 05 June 2023, 11:15:28 UTC pkg/endpoint: make GetNamedPorts lock-free [ upstream commit 3ca309d6e1da798126f55f8696663dfa07d62717 ] [ backporter's notes: 1. adjust types.NamedPortMap -> policy.NamedPortMap 2. EndpointInfoSource is in proxy/logger/epinfo.go instead of proxy/endpoint/endpoint.go 3. Go1.18 compat: atomic.Pointer -> atomic.Value ] This function is called deep within the policy generation hierarchy, and is at a risk of causing deadlocks. Given that it's just reading a pointer to a never-mutated map, we can safely stash this behind an atomic Pointer and remove the lock. Signed-off-by: Casey Callendrello <cdc@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 29 November 2023, 23:42:05 UTC
409f46c renovate[bot] 27 November 2023, 21:15:11 UTC chore(deps): update all lvh-images main Signed-off-by: renovate[bot] <bot@renovateapp.com> 29 November 2023, 20:26:46 UTC
23f56f9 Sebastian Wicki 22 November 2023, 15:51:32 UTC datapath: Fix ENI egress routing table for cilium_host IP [ upstream commit 0fcd1c86e347b2701880c9034e7ea3a74cd6b13e ] On ENI, we install source-based egress routing rules that steer traffic from Cilium-mananged IPs (i.e. pods, but also the health IP, ingress IP and router IP) to the correct egress interface. For pod IPs, this is done in the CNI plugin: https://github.com/cilium/cilium/blob/7875f6acb5a2fd2b0e3e6c993c9995c0d322e55d/plugins/cilium-cni/interface.go#L59-L63 For ingress and health IP, this is done from cilium-agent: https://github.com/cilium/cilium/blob/ed20c8acde8c76d405d6c9fac3c9de44aa3bb403/daemon/cmd/ipam.go#L401-L405 https://github.com/cilium/cilium/blob/e49430286b5d63b00062758a10a2b37458f94525/cilium-health/launch/endpoint.go#L329-L333 For the `cilium_host` (aka router) IP however, this was done differently. Commit f34371ce8f added a new `routing.SetupRules` function that duplicated parts of the `routing.RoutingInfo.Configure` logic, but missed a crucial part: Namely the creation of the per-ENI routing table that the source-based egress rule points towards. This means that if the `cilium_host` IP address was allocated from a different ENI than the pod, health and ingress IP addresses, that the routing table for that ENI was never created. This led to connectivity issues, in particular in combination with IPSec. This commit addresses that issue by having the `cilium_host` IP use the same code path as the other IP users: Using `RoutingInfo.Configure`. This not only fixes the bug, but removes some code that was otherwise only used for the router IP. There is one major difference between other users of `RoutingInfo.Configure` and the newly introduced use for the `cilium_host` IP: For the `cilium_host` IP, we skip the creation of the ingress rule (by passing in `host=true`), as otherwise the `cilium_host` IP would not be considered a local address of the host network namespace. This is consistent with the old `SetupRules` function did also not create such an ingress rule. Long-term, it remains questionable if the setup of egress rules in ENI mode should be left to IPAM clients, as every client seems to do it slightly differently. Maybe this is better done by either the IPAM subsystem or a separate device manager. Fixes: f34371ce8f27 ("ipam: Add routes for cilium_host ENI address") Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 28 November 2023, 11:02:10 UTC
93eb548 Sebastian Wicki 23 November 2023, 13:51:21 UTC eni/routing: Allow ingress rule to be skipped [ upstream commit db336796b6f723a8c0872476bb7058c4755b41ad ] This commit extends the `Configure` method of `RoutingInfo` with a flag to skip the creation of the ingress rule. The ingress rule is needed for endpoints such that those are forwarded via the `main` routing table. But for the `cilium_host` (aka. router) IP, we want to route it via the `local` table (which would be skipped by the ingress rule). Without a lookup in the `local` routing table, Linux will not consider `cilium_host` to be an address of the local host, and for example not respond to ICMP requests. Note that this commit does not yet use `RoutingInfo.Configure` to set up the `cilium_host` IP, this will be done in the next commit. This commit here merely prepares the method for that and does not contain any functional changes by itself (which can be observed by the fact that all callers pass in `host=false`). Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 28 November 2023, 11:02:10 UTC
3986585 Cilium Imagebot 27 November 2023, 09:59:59 UTC images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> 28 November 2023, 09:46:56 UTC
110405d renovate[bot] 27 November 2023, 09:47:24 UTC chore(deps): update docker.io/library/ubuntu:20.04 docker digest to ed4a422 Signed-off-by: renovate[bot] <bot@renovateapp.com> 28 November 2023, 09:46:56 UTC
038ef59 Tam Mach 27 November 2023, 09:23:30 UTC envoy: Bump envoy container image The new build is with golang 1.21.4 and grpc v1.59.0, mainly for recent HTTP/2 related CVEs. Related build: https://github.com/cilium/proxy/actions/runs/7002314626/job/19047286335 Relates: https://github.com/cilium/proxy/pull/439 Signed-off-by: Tam Mach <tam.mach@cilium.io> 28 November 2023, 03:26:26 UTC
22c5718 Quentin Monnet 26 October 2023, 15:56:38 UTC ci/ipsec: Skip upgrade/downgrade test to patch release on main branch [ upstream commit c9dedb49f5a65dda4af26af6ee79abe863153171 ] Skip upgrade/downgrade test to patch release when we fail to retrieve the number for the previous patch release. This happens mostly for the main branch (where testing upgrades/downgrades is covered by the tests to the previous stable (minor) release already). This may also happen on top of release preparation commits, where we set the patch number to 90, and where it is non-trivial to retrieve the previous patch release number. This case doesn't matter much, because commits for preparing releases are Not Expected To Break IPsec (TM). Signed-off-by: Quentin Monnet <quentin@isovalent.com> 28 November 2023, 03:21:37 UTC
83025ce Quentin Monnet 26 October 2023, 13:59:16 UTC ci/ipsec: Add upgrade/downgrade tests for patch releases [ upstream commit ed59edc9f34596c871e45430c9378579eed9a12a ] Currently, we test upgrades and downgrades for IPsec against the previous stable branch, for example: - On main branch (v1.15-dev): v1.14 (branch tip) -> main (PR HEAD) -> v1.14 (branch tip) - On older stable branches: v1.13 (branch tip) -> v1.14 (PR HEAD) -> v1.13 (branch tip) For stable branches, this commit adds support for testing upgrades and downgrades against the latest patch release as well, for example: - On v1.14: v1.14.4 (tag) -> v1.14 (PR HEAD) -> v1.14.4 (tag) The workflow currently fails on the main branch (this case is covered by the upgrade/downgrade test to the previous stable branch already). This is addressed by skipping most of the steps on main branch, in a follow-up commit. Signed-off-by: Quentin Monnet <quentin@isovalent.com> 28 November 2023, 03:21:37 UTC
a6d90de Martynas Pumputis 09 November 2023, 08:34:51 UTC ci-ipsec-upgrade: Add missed tail calls check for upgrade [ upstream commit ced884f22c62585431fe048c872897a009d3d064 ] The downgrade is still affected [1]. [1]: https://github.com/cilium/cilium/issues/26739#issuecomment-1803373334 Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 28 November 2023, 03:21:37 UTC
4734e3d Martynas Pumputis 09 November 2023, 08:27:54 UTC ci-ipsec-upgrade: Use branch tip instead of released version [ upstream commit 502bbc7bcc19c8a43c7a94a8ad9a16b1fb666e11 ] [1] changed the upgrade path from "v1.14 (branch tip) -> main -> v1.14 (branch tip)" to "v1.14.x (last release) -> main -> v1.14.x (last release)". The downside of the former path is that we catch any upgrade/downgrade regressions only after a release. This commit brings back the previous path. [1]: https://github.com/cilium/cilium/commit/31afd0211984f170f2844e455f6e48ad055e586d Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 28 November 2023, 03:21:37 UTC
8a20618 Gray Liang 08 September 2023, 06:47:35 UTC CI: Let actions/cilium-config use Chart.yaml-specified image by default [ upstream commit 31afd0211984f170f2844e455f6e48ad055e586d ] Previously cilium-config action always generates helm-set flags for image settings, but in some cases we can just rely on Chart.yaml since we always set chart-dir. This helps when: 1. We want to install release version instead of ci version. Currently cilium-config action sets `cilium-ci` unconditionally. 2. We have complicated image tag requirements such as `v1.14.1-beta.1`. Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 28 November 2023, 03:21:37 UTC
f3bc386 Quentin Monnet 26 October 2023, 13:39:03 UTC contrib/scripts: Support patch releases in print-downgrade-version.sh [ upstream commit 56dfec2f1ac5126bd5eeed3e30607b215e4ab991 ] Script contrib/scripts/print-downgrade-version.sh is used to derive the name of the previous stable branch, based on the current version number found in the repository. This is useful for testing upgrades and dowgrades in CI, between the current branch and the previous stable branch. For some tests we need to perform similar checks between the current tip of a branch and the latest patch release on the branch. For example, when working on branch 1.14, we want to downgrade to the latest patch release, 1.14.3 at this time, then upgrade back to the tip of 1.14. On the main branch, this is not relevant, because we don't usually have patch releases on that branch. The current commit updates print-downgrade-version.sh to add support for patch releases. When a user pass "patch" as first argument to the patch, then instead of decrementing the minor version by one, the script decrements the patch release number by one, and prints the results. When the patch release number is 0 (new minor release) or 90 (release preparation), the script returns an error, because it is non-trivial to find the preceding patch release number in such cases (at least without Git and the Git history). From the workflow's perspective (for supporting upgrades from patch releases in a follow-up commit), for new minor releases, update/downgrade is already covered in this case by working with the previous stable branch; and for 90, we just don't have an easy way to retrieve the previous number. We make the script print errors on stderr, in order to make it easier to compare the string returned on stdout (empty in case of error). Some examples of numbers from VERSION and the corresponding values returned: VERSION Previous minor Previous patch release 1.14.3 v1.13 v1.14.2 1.14.1 v1.13 v1.14.0 1.14.0 v1.13 <error> 1.14.1-dev v1.13 v1.14.0 1.15.0-dev v1.14 <error> 1.13.90 v1.12 <error> In order to test the script easily, this commit also allows setting $VERSION from the command line, defaulting to the content of file VERSION if no value is provided. Let's also add the errexit and nounset options to the script. Signed-off-by: Quentin Monnet <quentin@isovalent.com> 28 November 2023, 03:21:37 UTC
0c276e5 Michi Mutsuzaki 06 September 2023, 19:09:32 UTC Clean up tests-ipsec-upgrade workflow [ upstream commit d51a932aa483c5c9f24caf5eca72ae2752516e08 ] - Add a script to get the Cilium version to downgrade to instead of hardcoding it in the workflow file. The script uses the top-level VERSION file to infer the previous version. - Check out the git branch to get the Helm chart instead of doing a wget to download the source archive. Signed-off-by: Michi Mutsuzaki <michi@isovalent.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com> 28 November 2023, 03:21:37 UTC
04a4106 renovate[bot] 20 November 2023, 19:26:52 UTC chore(deps): update myrotvorets/set-commit-status-action action to v2 Signed-off-by: renovate[bot] <bot@renovateapp.com> 27 November 2023, 09:44:37 UTC
1e5983d Cilium Imagebot 19 November 2023, 00:01:00 UTC images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> 27 November 2023, 09:38:54 UTC
d875245 renovate[bot] 18 November 2023, 23:49:24 UTC chore(deps): update docker/dockerfile docker tag to v1.6 Signed-off-by: renovate[bot] <bot@renovateapp.com> 27 November 2023, 09:38:54 UTC
f7a5a42 renovate[bot] 18 November 2023, 23:49:18 UTC chore(deps): update docker/dockerfile docker tag to v1.6 Signed-off-by: renovate[bot] <bot@renovateapp.com> 27 November 2023, 09:37:16 UTC
cd66b4c renovate[bot] 18 November 2023, 23:49:11 UTC chore(deps): update docker/dockerfile docker tag to v1.6 Signed-off-by: renovate[bot] <bot@renovateapp.com> 27 November 2023, 09:37:05 UTC
0f12826 renovate[bot] 20 November 2023, 19:26:13 UTC chore(deps): update all lvh-images main Signed-off-by: renovate[bot] <bot@renovateapp.com> 24 November 2023, 10:38:02 UTC
8dd8379 Martynas Pumputis 15 November 2023, 13:19:51 UTC ci-ipsec-upgrade: Check for erros when upgrading [ upstream commit 38a705bfd9dc4c01e686c66fe82e1c8d93e310e3 ] See https://github.com/cilium/cilium-cli/pull/2110. Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Tam Mach <tam.mach@cilium.io> 24 November 2023, 09:19:46 UTC
6b369fe renovate[bot] 21 November 2023, 13:37:46 UTC chore(deps): update all github action dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> 22 November 2023, 11:12:18 UTC
31e0273 renovate[bot] 21 November 2023, 09:26:02 UTC chore(deps): update all github action dependencies Signed-off-by: renovate[bot] <bot@renovateapp.com> 21 November 2023, 13:34:58 UTC
e94b0f6 renovate[bot] 20 November 2023, 19:26:44 UTC chore(deps): update actions/github-script action to v7 Signed-off-by: renovate[bot] <bot@renovateapp.com> 21 November 2023, 10:51:44 UTC
804443f renovate[bot] 20 November 2023, 19:26:36 UTC chore(deps): update actions/checkout action to v4 Signed-off-by: renovate[bot] <bot@renovateapp.com> 21 November 2023, 08:30:33 UTC
aef5580 Martynas Pumputis 16 November 2023, 14:55:35 UTC ariane: Run ci-ipsec-upgrade when testing backports Signed-off-by: Martynas Pumputis <m@lambda.lt> 21 November 2023, 06:10:20 UTC
c91ad39 Tim Horner 15 November 2023, 20:59:14 UTC Revert dnsproxy: Use original source address in connections to dns servers This reverts commit 4357e7ab585d5cad7c45a8a8c41334d32ff97f7c. This change was reverted in main at 4dc8ca2. Since this was an author backport and required special care, I'm reverting the commit in the branch rather than backporting. [upstream commit 4dc8ca2 ] Signed-off-by: Tim Horner <timothy.horner@isovalent.com> 16 November 2023, 13:44:25 UTC
4764e4f David Bimmler 14 November 2023, 15:02:02 UTC endpoint: lock the selector cache for reading As in 52ace8e9ea318fe79e86731bddbc0abc97843311, there have been reports of a runtime crash with with following error: fatal error: concurrent map read and map write (This commit message is heavily inspired by the above commit in the hopes of achieving a similar level of clarity.) The path for this issue is printed also in the logs, with the following call stack: github.com/cilium/cilium/pkg/policy.(*SelectorCache).GetNetsLocked(...) github.com/cilium/cilium/pkg/policy.getNets(...) github.com/cilium/cilium/pkg/policy.identityIsSupersetOf(...) github.com/cilium/cilium/pkg/policy.(*mapState).DenyPreferredInsertWithChanges(...) Given the abovementioned commit has fixed the issue on main, there must be a different call stack present in 1.12. Indeed, as shown below, there's the flow involving `addNewRedirects` which isn't covered by locking in `DistillPolicy`. INCOMING CALLS GetNetsLocked github.com/cilium/cilium/pkg/policy • selectorcache.go getNets github.com/cilium/cilium/pkg/policy • mapstate.go identityIsSupersetOf github.com/cilium/cilium/pkg/policy • mapstate.go DenyPreferredInsertWithChanges github.com/cilium/cilium/pkg/policy • mapstate.go addNewRedirectsFromDesiredPolicy github.com/cilium/cilium/pkg/policy • bpf.go addNewRedirects github.com/cilium/cilium/pkg/endpoint • bpf.go <--- No SelectorCache lock DenyPreferredInsert github.com/cilium/cilium/pkg/policy • mapstate.go ToMapState github.com/cilium/cilium/pkg/policy • l4.go addNewRedirectsFromDesiredPolicy github.com/cilium/cilium/pkg/policy • bpf.go addNewRedirects github.com/cilium/cilium/pkg/endpoint • bpf.go <--- No SelectorCache lock computeDirectionL4PolicyMapEntries github.com/cilium/cilium/pkg/policy • resolve.go computeDesiredL4PolicyMapEntries github.com/cilium/cilium/pkg/policy • resolve.go DistillPolicy github.com/cilium/cilium/pkg/policy • resolve.go <--- SelectorCache.RLock() DetermineAllowLocalhostIngress github.com/cilium/cilium/pkg/policy • mapstate.go DistillPolicy github.com/cilium/cilium/pkg/policy • resolve.go <--- SelectorCache.RLock() computeDirectionL4PolicyMapEntries github.com/cilium/cilium/pkg/policy • resolve.go computeDesiredL4PolicyMapEntries github.com/cilium/cilium/pkg/policy • resolve.go DistillPolicy github.com/cilium/cilium/pkg/policy • resolve.go <--- SelectorCache.RLock() consumeMapChanges github.com/cilium/cilium/pkg/policy • mapstate.go ConsumeMapChanges github.com/cilium/cilium/pkg/policy • resolve.go <--- SelectorCache.Lock() Read the above tree as "GetNetsLocked() is called by getNets()", "getNets() is called by entryIdentityIsSupersetOf()", and so on. Siblings at the same level of indent represent alternate callers of the function that is one level of indentation less in the tree, ie addNewRedirectsFromDesiredPolicy and DenyPreferredInsert() both call DenyPreferredInsertWithChanges(). As annotated above, we see that calls through addNewRedirects() do not grab the SelectorCache lock. Given that consumeMapChanges() grabs the SelectorCache lock, we cannot introduce a new lock acquisition in any descendent function, otherwise it would introduce a deadlock in goroutines that follow that call path. This provides us the option to lock at some point from the sibling of consumeMapChanges() or higher in the call stack. As addNewRedirectsFromDesiredPolicy calls DenyPreferredInsertWithChanges both directly and indirectly (via ToMapState), it represents the lower bound of the call stack range where we can lock. The further up we traverse in the call stack, the greater the risk of a deadlock becomes, as more and more code now runs under the SelectorCache lock. Hence, we opt for locking at the lower bound, in addNewRedirectsFromDesiredPolicy. Unfortunately, this function lives in pkg endpoint, not policy, and we thus need to allow pkg-external access to the SelectorCache mutex, which is not great. The only silver lining is that this hack has an expiration time, as it is not present on main. Fixes: d68efba3de (endpoint: Remove GetLabelsLocked) Co-authored-by: Tobias Klauser <tobias@cilium.io> Signed-off-by: David Bimmler <david.bimmler@isovalent.com> 16 November 2023, 13:08:36 UTC
df576f3 Martynas Pumputis 15 November 2023, 09:02:13 UTC ci-ipsec-upgrade: Do not run conn tests after installing Cilium [ upstream commit 1fe228197cc7685a10dd38461d7a4b77ea4b8a95 ] The same connectivity tests should be run by ci-ipsec-e2e. Suggested-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> 15 November 2023, 20:31:02 UTC
3877d59 Nate Sweet 13 November 2023, 16:59:00 UTC install: Update image digests for v1.12.16 Generated from https://github.com/cilium/cilium/actions/runs/6852674790. `docker.io/cilium/cilium:v1.12.16@sha256:74d0c8d91821bf5fb7a7a7ad4acdebd6f74dd52ba1d1e3d40fa543a506a7ee14` `quay.io/cilium/cilium:v1.12.16@sha256:74d0c8d91821bf5fb7a7a7ad4acdebd6f74dd52ba1d1e3d40fa543a506a7ee14` `docker.io/cilium/clustermesh-apiserver:v1.12.16@sha256:de5b80e9c95c94e2605f9aaf59965c8c22dab80d94d34189adbe30e728476326` `quay.io/cilium/clustermesh-apiserver:v1.12.16@sha256:de5b80e9c95c94e2605f9aaf59965c8c22dab80d94d34189adbe30e728476326` `docker.io/cilium/docker-plugin:v1.12.16@sha256:74eb31f091fe94f62c423ca5eafa57006ff086901db7df26ce8d2aa0accb65e3` `quay.io/cilium/docker-plugin:v1.12.16@sha256:74eb31f091fe94f62c423ca5eafa57006ff086901db7df26ce8d2aa0accb65e3` `docker.io/cilium/hubble-relay:v1.12.16@sha256:503d39c3a2cb98d662f90c7952b58edbab1acff45abb212f8bb4c6ad607a7089` `quay.io/cilium/hubble-relay:v1.12.16@sha256:503d39c3a2cb98d662f90c7952b58edbab1acff45abb212f8bb4c6ad607a7089` `docker.io/cilium/operator-alibabacloud:v1.12.16@sha256:40a1e332e64735a5f91c2c286b738b200b7d96ceba1f9fd988dd9fcb818922bb` `quay.io/cilium/operator-alibabacloud:v1.12.16@sha256:40a1e332e64735a5f91c2c286b738b200b7d96ceba1f9fd988dd9fcb818922bb` `docker.io/cilium/operator-aws:v1.12.16@sha256:b29e4a4f6c068e3500cc2091c6c3bf144e704d60723a2c49ae43904ee414a37f` `quay.io/cilium/operator-aws:v1.12.16@sha256:b29e4a4f6c068e3500cc2091c6c3bf144e704d60723a2c49ae43904ee414a37f` `docker.io/cilium/operator-azure:v1.12.16@sha256:8226a2b106f76e7a37f20dd7216ba9bdd3bcbf5287a3b39ed21bcaffe34af21f` `quay.io/cilium/operator-azure:v1.12.16@sha256:8226a2b106f76e7a37f20dd7216ba9bdd3bcbf5287a3b39ed21bcaffe34af21f` `docker.io/cilium/operator-generic:v1.12.16@sha256:3132b821c1d3f617a1763ce32be8e42b33adfa8dbd267c7ec45f368794c5dcae` `quay.io/cilium/operator-generic:v1.12.16@sha256:3132b821c1d3f617a1763ce32be8e42b33adfa8dbd267c7ec45f368794c5dcae` `docker.io/cilium/operator:v1.12.16@sha256:076351699a55ec3b48753615cb24edb120e8fd8578d8a382fb01353de39d75b9` `quay.io/cilium/operator:v1.12.16@sha256:076351699a55ec3b48753615cb24edb120e8fd8578d8a382fb01353de39d75b9` Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 13 November 2023, 17:33:23 UTC
6b7226a Nate Sweet 12 November 2023, 20:38:13 UTC Prepare for release v1.12.16 Signed-off-by: Nate Sweet <nathanjsweet@pm.me> 13 November 2023, 15:22:28 UTC
f3dab6e Tam Mach 29 October 2023, 13:14:28 UTC envoy: Bump version to v1.26.6 This is as part of regular maintenance, also a preparation for upcoming work. Related build: https://github.com/cilium/proxy/actions/runs/6683414489/job/18159613808 Signed-off-by: Tam Mach <tam.mach@cilium.io> 10 November 2023, 19:02:34 UTC
4357e7a Jarno Rajahalme 09 November 2023, 15:16:02 UTC dnsproxy: Use original source address in connections to dns servers [ upstream commit 9d70db891f0b2b358db1ecee9180c528fa67f429 ] 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> info: patch template saved to `-` 10 November 2023, 08:37:48 UTC
5ce940f Tobias Klauser 18 August 2023, 10:01:41 UTC go.mod, vendor: use github.com/cilium/dns fork directly [ upstream commit 95e25bfb132750e97304dfbe0f5770f4b6debd96 ] We have been maintaining and using that fork for a long time and it looks like the custom changes won't make it upstream any time soon. There are no other vendored dependencies using miekg/dns, so switching to the cilium/dns fork shouldn't have any side effects. The fork's module name was changed to match its import path in https://github.com/cilium/dns/pull/4. Let's replace the github.com/miekg/dns import path by github.com/cilium/dns to get rid of another replace directive in go.mod and thus make life a tiny bit easier for downstream packages importing github.com/cilium/cilium. Signed-off-by: Tobias Klauser <tobias@cilium.io> 10 November 2023, 08:37:48 UTC
36b9f9d derailed 03 October 2023, 20:34:24 UTC Ensures prometheus metrics associated with a deleted node are no longer reported. [ upstream commit e9f97cd0e3ec55d448387bd27eb8fcf0b198936f ] When a node is deleted from a cluster, metrics associated with that node are still being exported to prometheus. Short of restarting the agent, we want to dynamically delete these metrics when a node is removed from the cluster. This PR ensures node_connectivity_status and node_connectivity_latency no longer report metrics for nodes that are no longer present on the cluster. [ Backporter's notes: Original PR was adapted! ] The original PR depends (mainly!) on 2 other PRs that haven't been backported and are fairly substential. Given this, I've opted to adapt the original implementation to surface the fix while minimizing impact with these updates: 1. pkg/metrics/interfaces did not introduce pkg/metrics/metric wrappers as of this release. Hence adapted deletableVec to use the current implementation. (Referring to commit: 84ea383) 2. pkg/node/manager/manager was adapted to provide for metrics deletion when a node is deleted. Subsequent PR refactored the manager metrics structure which the original PR used. (Referring to commit: c49ef45) 3. In order to pickup prom metrics vec delete feature github.com/prometheus/client_golang dep was bumped to v1.14.0 Signed-off-by: Fernand Galiana <fernand.galiana@isovalent.com> 08 November 2023, 21:45:52 UTC
49c4495 Cilium Imagebot 08 November 2023, 10:14:14 UTC images: update cilium-{runtime,builder} Signed-off-by: Cilium Imagebot <noreply@cilium.io> 08 November 2023, 21:26:55 UTC
8ce1d8f renovate[bot] 08 November 2023, 09:16:19 UTC chore(deps): update docker.io/library/golang docker tag to v1.20.11 Signed-off-by: renovate[bot] <bot@renovateapp.com> 08 November 2023, 21:26:55 UTC
8335dfc Paul Chaignon 25 October 2023, 18:12:21 UTC cmd: Unit test for parseNodeID [ upstream commit 550b56e1f8bfe601abd569368461cb8e8529aef1 ] Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
9b82b7d Paul Chaignon 25 October 2023, 17:10:55 UTC cmd: New flag to flush only XFRM configs for a given node ID [ upstream commit 0e5d3c3a4f08a0ea857710ead700528b95b71b3d ] This can be useful to flush the XFRM configs of stale node IDs. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
ecee70e Paul Chaignon 25 October 2023, 17:10:07 UTC ipsec: Move getNodeIDFromXfrmMark to pkg/common [ upstream commit 47e1b3f2fa9e990bde778129677341a5b6784d35 ] We will use this function from cilium-dbg in the subsequent commit. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
b0597a1 Paul Chaignon 25 October 2023, 18:35:39 UTC cmd: Unit test for the filterXFRMs function [ upstream commit c924bd617796e854342b31f691cae55870a21131 ] We test both a single call to filterXFRMs and two chained calls. The latter is because we will need to chain calls for different filters because they are ANDed. For example, filtering on both the SPI and the node ID should only flush XFRM configs that match for both the given SPI and node ID. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
4202f74 Paul Chaignon 25 October 2023, 16:58:13 UTC cmd: Refactor XFRM filter function to ease generalization [ upstream commit dd8920a5c93ed55a217cf2bca0c81ba28123efdb ] Refactor the filterXFRMBySPI function to be able to filter by other things than SPI without duplicating the main logic. The new function filterXFRMs takes two predicate functions instead of hardcoding the comparison to "spi". No functional changes in this commit. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
10befa0 Paul Chaignon 25 October 2023, 15:32:40 UTC cmd: New flag to flush only XFRM configs for given SPI [ upstream commit 5c7cfe67954f8afdd48750770f76782553ca845f ] This is useful to for example manually delete the XFRM config corresponding to an old key. It will warn if the user is about to delete all XFRM configs on the assumption that that isn't the intended action or the filter wouldn't be necessary. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
b0f0c53 Paul Chaignon 25 October 2023, 15:20:15 UTC cmd: Add confirmation to encrypt flush command [ upstream commit 37b611ee290264f135834a77dd488d9c17f33226 ] The cilium-dbg encrypt flush command removes all XFRM states and policies on the node. That will lead to packet drops until connections are reestablished. Traffic will also be sent in plain text between pods. This commit therefore asks for confirmation when running the command, to ensure nobody performs this action by mistake. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
65381dc Paul Chaignon 25 October 2023, 16:40:30 UTC ipsec: Move getSPIFromXfrmPolicy to pkg/common [ upstream commit fe087721bef0aa0a0ec93bf015e9659f8acc85b9 ] This function will be used from cilium-dbg so we need to expose it from a shared package. We already have such a package for IPsec utility functions in pkg/common/ipsec. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
262ab44 Paul Chaignon 17 October 2023, 11:05:09 UTC ipsec: Log node ID in hex format for consistency [ upstream commit 4506c766ec657086f952336dc93a96df1a993894 ] The node ID is reported in hexadecimal format in the XFRM states and policies, as well as in the node ID map dump. To make it easier to match the node ID across different sources, we should also dump it in hex format in the agent logs. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
d8bdad7 Paul Chaignon 17 October 2023, 10:59:40 UTC ipsec: Log node ID and direction whenever possible [ upstream commit 89626bcabc6b675b2f67839632d4e84ea91e155b ] The SPI and the source and destination IP addresses (or CIDRs for XFRM policies) are not enough anymore to uniquely identify XFRM states and policies. We additionally need the node ID. This commit therefore ensures that we always log the five contextual information bits whenever possible: SPI, source, destination, direction, and node ID. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
88081f1 Paul Chaignon 17 October 2023, 10:57:39 UTC ipsec: Helper function to get direction from XFRM mark [ upstream commit e27730b7d3fae124965b313d53243d62b236abb2 ] This is useful for XFRM states which do not have a built-in direction field. Instead, we encode the direction in the packet mark and can therefore rely on that when logging. The same function can be used for XFRM policies, even though they do have a built-in Dir field as well. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> 08 November 2023, 15:15:59 UTC
d38cf56 Tam Mach 01 November 2023, 12:20:59 UTC bpf: Add TC_ACT_REDIRECT check for nodeport [ upstream commit 80d99a60f9e4021842001ea2711807982d9dca20 ] [ backporter's notes: minor conflicts as nodeport_lb{4,6} differ from the ones in main] Relates: https://github.com/cilium/cilium/pull/18894\#discussion_r1373896641 Signed-off-by: Tam Mach <tam.mach@cilium.io> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 08 November 2023, 15:15:59 UTC
13c4cbf Paul Chaignon 02 November 2023, 10:58:31 UTC datapath: Move linuxNodeHandler IPsec functions to their own file [ upstream commit 1900f4a1888ec9d24bd7db779e30d2b21cacfb7d ] [ backporter's notes: a few conflicts to deal with, as the IPSec methods differ from the ones in main, so I just manually moved all the methods from node.go to ipsec.go ] This commit has no functional changes. It simply moves all the linuxNodeHandler functions that pertain to IPsec to a new file, ipsec.go. This will ease review assignments by ensuring that we don't require an IPsec review on non-IPsec code and vice versa. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 08 November 2023, 15:15:59 UTC
226a2fc Julian Wiedmann 31 October 2023, 07:06:04 UTC bpf: lb: fix missing drop reason in reverse_map_l4_port() [ upstream commit 28a3cb7077aec3b03e54b873765cb764b0d46fa0 ] l4_load_port() is just a thin wrapper around ctx_load_bytes(), which returns raw kernel errnos. Translate these to a Cilium-internal drop reason before returning to the caller. Signed-off-by: Julian Wiedmann <jwi@isovalent.com> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 08 November 2023, 15:15:59 UTC
9a396e4 Martynas Pumputis 26 October 2023, 10:04:50 UTC gh/workflows: Dump Cilium LB node logs in case of failure [ upstream commit 904ceb3d3d207da470b0106c2921de8777c98d9e ] The Cilium standalone LB does not run as a K8s pod, so the regular Cilium's sysdump collection does not work. Instead, just show docker container logs of the LB. Suggested-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Gilberto Bertin <jibi@cilium.io> 08 November 2023, 15:15:59 UTC
a0ef41a Fabio Falzoi 06 November 2023, 16:14:45 UTC ci: Use pull_request_target in update label workflow When the workflow is triggered from a PR opened in a fork, it fails with the following message: `GraphQL: Resource not accessible by integration (removeLabelsFromLabelable)` To fix this, we need to run the workflow in the context of the pull request base, so the commit changes the event to be `pull_request_target` instead of `pull_request`. Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 07 November 2023, 09:33:07 UTC
417de59 Fabio Falzoi 17 October 2023, 12:12:05 UTC labels/cidr: On the fly char replacement for IPv6 [ upstream commit b448f92c8aefb7003038dc1d879facb076f29456 ] When generating labels for IPv6 addresses, ':' characters need to be replaced with '-'. Also, a leading or trailing '0' is added to avoid labels starting or ending with '-'. To avoid the allocation of an additional string, replace the character on the fly while accumulating the label key in the strings.Builder. IPStringToLabel/0.0.0.0/0-8 104ns ±11% 94ns ± 4% -10.25% (p=0.008 n=5+5) IPStringToLabel/192.0.2.3-8 146ns ± 3% 128ns ±27% ~ (p=0.841 n=5+5) IPStringToLabel/192.0.2.3/32-8 175ns ±11% 190ns ± 8% ~ (p=0.056 n=5+5) IPStringToLabel/192.0.2.3/24-8 176ns ±12% 167ns ± 7% ~ (p=0.095 n=5+5) IPStringToLabel/192.0.2.0/24-8 169ns ± 2% 162ns ± 1% -4.08% (p=0.008 n=5+5) IPStringToLabel/::/0-8 309ns ± 2% 232ns ±11% -24.91% (p=0.008 n=5+5) IPStringToLabel/fdff::ff-8 412ns ± 1% 264ns ± 1% -35.90% (p=0.008 n=5+5) IPStringToLabel/f00d:42::ff/128-8 469ns ± 2% 305ns ± 1% -34.96% (p=0.016 n=5+4) IPStringToLabel/f00d:42::ff/96-8 405ns ±11% 293ns ± 7% -27.58% (p=0.008 n=5+5) name old alloc/op new alloc/op delta IPStringToLabel/0.0.0.0/0-8 24.0B ± 0% 24.0B ± 0% ~ (all equal) IPStringToLabel/192.0.2.3-8 32.0B ± 0% 32.0B ± 0% ~ (all equal) IPStringToLabel/192.0.2.3/32-8 32.0B ± 0% 32.0B ± 0% ~ (all equal) IPStringToLabel/192.0.2.3/24-8 32.0B ± 0% 32.0B ± 0% ~ (all equal) IPStringToLabel/192.0.2.0/24-8 32.0B ± 0% 32.0B ± 0% ~ (all equal) IPStringToLabel/::/0-8 16.0B ± 0% 16.0B ± 0% ~ (all equal) IPStringToLabel/fdff::ff-8 56.0B ± 0% 32.0B ± 0% -42.86% (p=0.008 n=5+5) IPStringToLabel/f00d:42::ff/128-8 80.0B ± 0% 32.0B ± 0% -60.00% (p=0.008 n=5+5) IPStringToLabel/f00d:42::ff/96-8 48.0B ± 0% 32.0B ± 0% -33.33% (p=0.008 n=5+5) name old allocs/op new allocs/op delta IPStringToLabel/0.0.0.0/0-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) IPStringToLabel/192.0.2.3-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) IPStringToLabel/192.0.2.3/32-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) IPStringToLabel/192.0.2.3/24-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) IPStringToLabel/192.0.2.0/24-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) IPStringToLabel/::/0-8 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.008 n=5+5) IPStringToLabel/fdff::ff-8 5.00 ± 0% 3.00 ± 0% -40.00% (p=0.008 n=5+5) IPStringToLabel/f00d:42::ff/128-8 5.00 ± 0% 3.00 ± 0% -40.00% (p=0.008 n=5+5) IPStringToLabel/f00d:42::ff/96-8 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.008 n=5+5) Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 06 November 2023, 14:16:44 UTC
38605cc Fabio Falzoi 17 October 2023, 13:09:14 UTC labels: Use slices.Sort instead of sort.Strings [ upstream commit d6e3eda7c848298e42e714dcfe2f93e3ede8739e ] As suggested by package "sort" documentation (https://pkg.go.dev/sort#Strings), slices.Sort should be preferred to sort.Strings since it runs faster. Comparison between sort.Strings ("old") and slices.Sort ("new"): name old time/op new time/op delta pkg:github.com/cilium/cilium/pkg/labels goos:linux goarch:amd64 Labels_SortedList-8 787ns ± 4% 736ns ±12% -6.42% (p=0.014 n=7+8) pkg:github.com/cilium/cilium/pkg/labels/cidr goos:linux goarch:amd64 Labels_SortedListCIDRIDs-8 5.22µs ± 8% 4.67µs ± 4% -10.63% (p=0.000 n=10+10) name old alloc/op new alloc/op delta pkg:github.com/cilium/cilium/pkg/labels goos:linux goarch:amd64 Labels_SortedList-8 360B ± 0% 336B ± 0% -6.67% (p=0.000 n=10+10) pkg:github.com/cilium/cilium/pkg/labels/cidr goos:linux goarch:amd64 Labels_SortedListCIDRIDs-8 1.62kB ± 0% 1.60kB ± 0% -1.48% (p=0.000 n=10+10) name old allocs/op new allocs/op delta pkg:github.com/cilium/cilium/pkg/labels goos:linux goarch:amd64 Labels_SortedList-8 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.000 n=10+10) pkg:github.com/cilium/cilium/pkg/labels/cidr goos:linux goarch:amd64 Labels_SortedListCIDRIDs-8 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.000 n=10+10) Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 06 November 2023, 14:16:44 UTC
136b955 Fabio Falzoi 25 October 2023, 09:36:01 UTC labels: Halve CIDR labels LRU cache size [ upstream commit 6f1253ef83c0615dbef6e7227feb27e6b3a1d4b1 ] After fixing the GetCIDRLabels implementation to generate all the labels required for a CIDR, the heap usage of the LRU cache increased 10x in the worst case (all IPv6 labels). To reduce heap usage, the cache size is halved, resulting in ~25 MiB in the IPv6 only case with roughly the same performance. === RUN TestCIDRLabelsCacheHeapUsageIPv4 cidr_test.go:527: Memoization map heap usage: 1714.41 KiB --- PASS: TestCIDRLabelsCacheHeapUsageIPv4 (0.67s) === RUN TestCIDRLabelsCacheHeapUsageIPv6 cidr_test.go:571: Memoization map heap usage: 26527.13 KiB --- PASS: TestCIDRLabelsCacheHeapUsageIPv6 (0.71s) name old time/op new time/op delta GetCIDRLabels/0.0.0.0/0-8 198ns ±40% 238ns ±34% ~ (p=0.325 n=10+10) GetCIDRLabels/10.16.0.0/16-8 1.32µs ± 8% 1.33µs ± 8% ~ (p=0.812 n=10+10) GetCIDRLabels/192.0.2.3/32-8 2.41µs ± 3% 2.39µs ± 5% ~ (p=0.278 n=10+9) GetCIDRLabels/192.0.2.3/24-8 2.05µs ± 2% 2.05µs ± 1% ~ (p=0.948 n=9+9) GetCIDRLabels/192.0.2.0/24-8 2.05µs ± 2% 2.04µs ± 1% ~ (p=0.797 n=9+8) GetCIDRLabels/::/0-8 277ns ±31% 257ns ± 1% ~ (p=0.349 n=10+8) GetCIDRLabels/fdff::ff/128-8 9.02µs ± 6% 8.80µs ± 3% ~ (p=0.077 n=9+9) GetCIDRLabels/f00d:42::ff/128-8 9.40µs ± 6% 9.01µs ± 5% -4.12% (p=0.035 n=10+10) GetCIDRLabels/f00d:42::ff/96-8 7.78µs ± 4% 7.58µs ± 1% -2.59% (p=0.011 n=8+9) GetCIDRLabelsConcurrent/1-8 189µs ± 8% 173µs ± 3% -8.85% (p=0.000 n=10+9) GetCIDRLabelsConcurrent/2-8 350µs ± 2% 346µs ± 1% -1.05% (p=0.001 n=8+8) GetCIDRLabelsConcurrent/4-8 703µs ± 1% 692µs ± 1% -1.59% (p=0.000 n=9+9) GetCIDRLabelsConcurrent/16-8 2.97ms ± 7% 2.91ms ± 1% ~ (p=0.122 n=10+8) GetCIDRLabelsConcurrent/32-8 5.81ms ± 1% 5.77ms ± 1% -0.57% (p=0.011 n=8+9) GetCIDRLabelsConcurrent/48-8 8.87ms ± 6% 8.71ms ± 1% ~ (p=0.139 n=9+8) name old alloc/op new alloc/op delta GetCIDRLabels/0.0.0.0/0-8 624B ± 0% 624B ± 0% ~ (all equal) GetCIDRLabels/10.16.0.0/16-8 2.40kB ± 0% 2.40kB ± 0% ~ (all equal) GetCIDRLabels/192.0.2.3/32-8 5.01kB ± 0% 5.01kB ± 0% ~ (all equal) GetCIDRLabels/192.0.2.3/24-8 4.93kB ± 0% 4.93kB ± 0% ~ (all equal) GetCIDRLabels/192.0.2.0/24-8 4.93kB ± 0% 4.93kB ± 0% ~ (all equal) GetCIDRLabels/::/0-8 624B ± 0% 624B ± 0% ~ (all equal) GetCIDRLabels/fdff::ff/128-8 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) GetCIDRLabels/f00d:42::ff/128-8 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) GetCIDRLabels/f00d:42::ff/96-8 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) GetCIDRLabelsConcurrent/1-8 321kB ± 0% 321kB ± 0% ~ (p=0.645 n=10+10) GetCIDRLabelsConcurrent/2-8 641kB ± 0% 641kB ± 0% ~ (p=0.796 n=10+10) GetCIDRLabelsConcurrent/4-8 1.28MB ± 0% 1.28MB ± 0% ~ (p=0.353 n=10+10) GetCIDRLabelsConcurrent/16-8 5.13MB ± 0% 5.13MB ± 0% ~ (p=0.083 n=10+8) GetCIDRLabelsConcurrent/32-8 10.3MB ± 0% 10.3MB ± 0% ~ (p=0.481 n=10+10) GetCIDRLabelsConcurrent/48-8 15.4MB ± 0% 15.4MB ± 0% ~ (p=0.796 n=10+10) name old allocs/op new allocs/op delta GetCIDRLabels/0.0.0.0/0-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/10.16.0.0/16-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/192.0.2.3/32-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/192.0.2.3/24-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/192.0.2.0/24-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/::/0-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/fdff::ff/128-8 3.00 ± 0% 3.00 ± 0% ~ (all equal) GetCIDRLabels/f00d:42::ff/128-8 3.00 ± 0% 3.00 ± 0% ~ (all equal) GetCIDRLabels/f00d:42::ff/96-8 3.00 ± 0% 3.00 ± 0% ~ (all equal) GetCIDRLabelsConcurrent/1-8 138 ± 0% 138 ± 0% ~ (all equal) GetCIDRLabelsConcurrent/2-8 277 ± 0% 277 ± 0% ~ (all equal) GetCIDRLabelsConcurrent/4-8 555 ± 0% 555 ± 0% ~ (all equal) GetCIDRLabelsConcurrent/16-8 2.22k ± 0% 2.22k ± 0% ~ (p=0.176 n=10+7) GetCIDRLabelsConcurrent/32-8 4.44k ± 0% 4.44k ± 0% ~ (p=0.867 n=10+10) GetCIDRLabelsConcurrent/48-8 6.66k ± 0% 6.66k ± 0% ~ (p=0.682 n=8+10) Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
7e66aed Fabio Falzoi 25 October 2023, 08:46:36 UTC labels: Refactor CIDRLabelsCacheHeapUsage into tests [ upstream commit 71b7ad5c46b56939002dd4de0dbc6852f01351e2 ] TestCIDRLabelsCacheHeapUsageIP{v4,v6} are meant to estimate the maximum heap usage when filling up the CIDR labels LRU cache with labels derived only from IPv4 and labels derived only from IPv6. Since they give meaningful results only when running them with benchtime=1x, thery are refactored to be just tests with a t.Log() to output the heap usage statistics. Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
ed3da84 Fabio Falzoi 25 October 2023, 08:32:02 UTC labels: Move away from checker for CIDR labels testing [ upstream commit 9f2034e6f968c5aacac5183f79055c9e1c532ac2 ] Migrate remaining tests relying on checker to the testing package from Go standard library. Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
3ebd187 Fabio Falzoi 24 October 2023, 18:31:19 UTC labels/cidr: Improve CIDR labels testing [ upstream commit 1b9b3fc16059738d5a0d9db9848507d193d31867 ] After the introduction of a LRU cache in GetCIDRLabels, the tests should verify the labels computation both when the cache is cold but also when it is hot. Thus, the tests are refactored to check the returned labels twice. Also, an additional test is added to verify that the labels stay consistent when we call GetCIDRLabels with the following sequences of prefixes: 1) "xxx/32", "xxx/31", ..., "xxx/0", "xxx/1", ..., "xxx/32" 2) "xxx/0", "xxx/1", ..., "xxx/32", "xxx/31", ..., "xxx/0" Finally, InCluster tests are removed since cluster identity does not exist anymore. Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
0af5f86 Fabio Falzoi 24 October 2023, 17:32:42 UTC labels/cidr: Fix labels memoization in GetCIDRLabels [ upstream commit 55517ea5e7fced563ef61ef031277c3b95526543 ] The previous version of the implementation was actually computing the labels starting from broader prefixes to narrower ones (first "/0", then "/1" and so on). As soon as we had a cache hit, the recursion stopped without calculating the remaining labels for the CIDRs up to "ones". This produced an incorrect (shorter) set of labels for a CIDR. Also, netip.PrefixFrom(...) does not mask the internally stored address, thus lowering the cache hit ratio even if two different CIDRs, used as keys in the LRU cache, are equal in terms of masked address. (e.g: "1.1.1.1/16" and "1.1.0.0/16"). So, netip.Addr.Prefix(...) is used instead. After the fix, the performance are roughly equal (but with an increased chance of having a cache hit). Instead, the maximum heap usage in the worst case (LRU cache filled up with IPv6 labels) is increased 10x. BenchmarkCIDRLabelsCacheHeapUsageIPv4 cidr_test.go:628: Memoization map heap usage: 5483.24 KiB BenchmarkCIDRLabelsCacheHeapUsageIPv6 cidr_test.go:670: Memoization map heap usage: 54721.70 KiB name old time/op new time/op delta GetCIDRLabels/0.0.0.0/0-8 256ns ±39% 218ns ±46% ~ (p=0.393 n=10+10) GetCIDRLabels/10.16.0.0/16-8 1.35µs ± 3% 1.39µs ± 5% +2.66% (p=0.012 n=9+10) GetCIDRLabels/192.0.2.3/32-8 2.52µs ± 2% 2.58µs ± 2% +2.58% (p=0.001 n=10+9) GetCIDRLabels/192.0.2.3/24-8 2.57µs ± 1% 2.24µs ± 3% -12.69% (p=0.000 n=8+10) GetCIDRLabels/192.0.2.0/24-8 2.27µs ± 4% 2.26µs ± 3% ~ (p=0.690 n=9+8) GetCIDRLabels/::/0-8 277ns ± 2% 278ns ± 3% ~ (p=0.796 n=9+9) GetCIDRLabels/fdff::ff/128-8 9.42µs ± 1% 9.34µs ± 6% ~ (p=0.484 n=9+10) GetCIDRLabels/f00d:42::ff/128-8 9.58µs ± 2% 9.62µs ± 7% ~ (p=0.905 n=10+9) GetCIDRLabels/f00d:42::ff/96-8 9.63µs ± 1% 8.45µs ± 3% -12.27% (p=0.000 n=8+9) GetCIDRLabelsConcurrent/1-8 205µs ± 3% 207µs ± 3% ~ (p=0.356 n=9+10) GetCIDRLabelsConcurrent/2-8 385µs ± 5% 386µs ± 7% ~ (p=0.631 n=10+10) GetCIDRLabelsConcurrent/4-8 784µs ± 5% 780µs ± 1% ~ (p=0.156 n=10+9) GetCIDRLabelsConcurrent/16-8 3.24ms ± 1% 3.25ms ± 2% ~ (p=0.529 n=10+10) GetCIDRLabelsConcurrent/32-8 6.40ms ± 1% 6.39ms ± 3% ~ (p=0.497 n=9+10) GetCIDRLabelsConcurrent/48-8 9.69ms ± 1% 10.09ms ± 6% +4.09% (p=0.008 n=8+9) name old alloc/op new alloc/op delta GetCIDRLabels/0.0.0.0/0-8 624B ± 0% 624B ± 0% ~ (all equal) GetCIDRLabels/10.16.0.0/16-8 2.40kB ± 0% 2.40kB ± 0% ~ (all equal) GetCIDRLabels/192.0.2.3/32-8 5.01kB ± 0% 5.01kB ± 0% ~ (all equal) GetCIDRLabels/192.0.2.3/24-8 5.01kB ± 0% 4.93kB ± 0% -1.64% (p=0.002 n=8+10) GetCIDRLabels/192.0.2.0/24-8 4.93kB ± 0% 4.93kB ± 0% ~ (all equal) GetCIDRLabels/::/0-8 624B ± 0% 624B ± 0% ~ (all equal) GetCIDRLabels/fdff::ff/128-8 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) GetCIDRLabels/f00d:42::ff/128-8 18.5kB ± 0% 18.5kB ± 0% ~ (p=0.108 n=9+10) GetCIDRLabels/f00d:42::ff/96-8 18.5kB ± 0% 18.5kB ± 0% -0.06% (p=0.000 n=10+10) GetCIDRLabelsConcurrent/1-8 321kB ± 0% 321kB ± 0% ~ (p=0.127 n=10+8) GetCIDRLabelsConcurrent/2-8 641kB ± 0% 641kB ± 0% ~ (p=0.928 n=10+10) GetCIDRLabelsConcurrent/4-8 1.28MB ± 0% 1.28MB ± 0% ~ (p=0.853 n=10+10) GetCIDRLabelsConcurrent/16-8 5.13MB ± 0% 5.13MB ± 0% ~ (p=0.739 n=10+10) GetCIDRLabelsConcurrent/32-8 10.3MB ± 0% 10.3MB ± 0% ~ (p=0.218 n=10+10) GetCIDRLabelsConcurrent/48-8 15.4MB ± 0% 15.4MB ± 0% ~ (p=0.218 n=10+10) name old allocs/op new allocs/op delta GetCIDRLabels/0.0.0.0/0-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/10.16.0.0/16-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/192.0.2.3/32-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/192.0.2.3/24-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/192.0.2.0/24-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/::/0-8 2.00 ± 0% 2.00 ± 0% ~ (all equal) GetCIDRLabels/fdff::ff/128-8 3.00 ± 0% 3.00 ± 0% ~ (all equal) GetCIDRLabels/f00d:42::ff/128-8 3.00 ± 0% 3.00 ± 0% ~ (all equal) GetCIDRLabels/f00d:42::ff/96-8 3.00 ± 0% 3.00 ± 0% ~ (all equal) GetCIDRLabelsConcurrent/1-8 138 ± 0% 138 ± 0% ~ (all equal) GetCIDRLabelsConcurrent/2-8 277 ± 0% 277 ± 0% ~ (all equal) GetCIDRLabelsConcurrent/4-8 555 ± 0% 555 ± 0% ~ (p=0.248 n=10+9) GetCIDRLabelsConcurrent/16-8 2.22k ± 0% 2.22k ± 0% ~ (p=0.353 n=7+10) GetCIDRLabelsConcurrent/32-8 4.44k ± 0% 4.44k ± 0% ~ (p=0.723 n=10+10) GetCIDRLabelsConcurrent/48-8 6.66k ± 0% 6.66k ± 0% ~ (p=0.090 n=10+9) Fixes: e0f6c47ea4 ("labels/cidr: Cache GetCIDRLabels computation") Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
c860883 Paul Chaignon 25 October 2023, 14:22:36 UTC bugtool: Collect XFRM error counters twice [ upstream commit c1803baeefde5b7bf8d4845eddd3b5653e5ef85a ] This commit changes the bugtool report to collect the XFRM error counters (i.e., /proc/net/xfrm_stat) twice instead of only once. We will collect at the beginning and end of the bugtool collection. In that way, there will be around 5-6 seconds between the two collections and we may see if any counter is currently increasing. $ diff cilium-bugtool-cilium-7d54p-20231025-115151/cmd/cat*--proc-net-xfrm_stat.md 5c5 < XfrmInStateProtoError 4 --- > XfrmInStateProtoError 6 In this example, we can easily see that the XfrmInStateProtoError is increasing. That suggests a key rotation issue is currently ongoing (cf. IPsec troubleshooting docs). I tried other approaches to collect over a longer timespan. That may allow us to see slower increases. They all end up being more complex or messier (we'd need to collect at beginning and end of the sysdump instead). In the end, considering this is already a fallback plan for when customers don't collect Prometheus metrics, I think the current, simpler approach is good enough. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
7470540 Marco Iorio 24 October 2023, 16:19:03 UTC gha: test geneve tunneling in addition to vxlan [ upstream commit 77e09f52168eb777b4f62d83b3bd5e75966479bf ] Switch one of the matrix entries currently configuring vxlan tunneling to geneve, so that we appropriately cover both protocols in combination with clustermesh. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
0de9071 Fabio Falzoi 13 October 2023, 10:48:53 UTC labels/cidr: Add benchmark for concurrent exection of GetCIDRLabels [ upstream commit 85aef68cd841586acddc05dfeda7da2cfd60845e ] Adding a LRU cache to memoize GetCIDRLabels means sharing state between different goroutines concurrently executing GetCIDRLabels. To measure the scalability of the LRU cache + mutex approach against the non-cached previous version, a benchmark with increasing number of goroutines is added. Running the benchmark against the current version and the one without labels memoization shows that the change gives a performance improvement even when up to 48 goroutines compete for the exclusive access to the LRU cache: name old time/op new time/op delta GetCIDRLabelsConcurrent/1-8 493µs ±31% 259µs ± 4% -47.54% (p=0.000 n=20+9) GetCIDRLabelsConcurrent/2-8 889µs ±10% 474µs ± 5% -46.69% (p=0.000 n=19+10) GetCIDRLabelsConcurrent/4-8 1.74ms ± 3% 0.89ms ± 4% -49.04% (p=0.000 n=20+10) GetCIDRLabelsConcurrent/16-8 7.14ms ± 6% 3.77ms ± 8% -47.20% (p=0.000 n=18+10) GetCIDRLabelsConcurrent/32-8 14.3ms ± 6% 7.3ms ± 2% -48.69% (p=0.000 n=20+9) GetCIDRLabelsConcurrent/48-8 21.9ms ± 5% 11.1ms ± 3% -49.24% (p=0.000 n=19+10) Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
967c2e0 Fabio Falzoi 13 October 2023, 10:47:23 UTC cidr/labels: Add benchmark for cache heap usage [ upstream commit ebfaa3088c869f9c4d1c77315d564e582ec0766f ] Add a benchmark to estimate the heap usage of a full CIDR labels LRU cache. Results show that heap usage is less than ~5 MiB: $ go test ./pkg/labels/cidr/... -run=^$ -bench="BenchmarkCIDRLabelsCacheHeapUsage" -benchtime=1x --- BENCH: BenchmarkCIDRLabelsCacheHeapUsageIPv4-8 cidr_test.go:396: Memoization map heap usage: 4146.02 KiB --- BENCH: BenchmarkCIDRLabelsCacheHeapUsageIPv6-8 cidr_test.go:438: Memoization map heap usage: 4571.74 KiB The benchmark must be called with `-benchtime=1x` to get meaningful values from `runtime.ReadMemStats`. For that reason, it is skipped by default. Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com> 02 November 2023, 15:18:52 UTC
back to top