From 77123ed8811f4d1756e6f9efd6e04317e1e9ed2c Mon Sep 17 00:00:00 2001 From: Yiannis Psaras <52073247+yiannisbot@users.noreply.github.com> Date: Sun, 7 May 2023 21:15:42 +0300 Subject: [PATCH] Update src/_blog/2023-05-ipfs-unresponsive-nodes-incident.md Co-authored-by: Steve Loeppky --- src/_blog/2023-05-ipfs-unresponsive-nodes-incident.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/_blog/2023-05-ipfs-unresponsive-nodes-incident.md b/src/_blog/2023-05-ipfs-unresponsive-nodes-incident.md index a125e5b8..e88107d4 100644 --- a/src/_blog/2023-05-ipfs-unresponsive-nodes-incident.md +++ b/src/_blog/2023-05-ipfs-unresponsive-nodes-incident.md @@ -84,7 +84,7 @@ The team’s immediate focus became: 1. [Adding/updating documentation on Kubo’s resource manager integration](https://github.com/ipfs/kubo/blob/master/docs/libp2p-resource-management.md) 2. Triaging and responding to user questions/issues ([example](https://github.com/ipfs/kubo/issues/9432)) -3. Preparing a new kubo release (`v0.18.1`), where the default settings for the resource manager were set to more appropriate values. This reduced the need that someone would need to adjust the resource manager configuration manually, thus avoiding the configuration “footguns”. +3. Preparing a new kubo release (`v0.18.1`), where the default settings for the resource manager were set to more appropriate values. This reduced the likelihood that someone would need to adjust the resource manager configuration manually, thus avoiding the configuration “footguns”. 4. Encouraging as many nodes as possible to upgrade through public forums and direct relationships with known larger scale operators In parallel, we kept monitoring the situation by instrumenting a PUT and GET measurement experiment that was running since before the `kubo-v0.18.1` update, when the affected nodes started updating gradually.