fix(k3s): keep reserve setup best effort - #2127
Conversation
|
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
You do not have enough credits to review this pull request. Please purchase more credits to continue. |
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request improves the robustness of the activate.sh script by caching the output of tune2fs to avoid redundant executions, adding error handling for filesystem configuration, and updating tests and documentation. The review feedback highlights a critical bug in the require_sudo helper function, which lacks an explicit return 0 and causes the script to skip filesystem inspection when sudo is available. Additionally, it is recommended to use Bash here-strings (<<<) instead of piping printf to awk to avoid spawning unnecessary subshells.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| fi | ||
|
|
||
| require_sudo || return 0 | ||
| if ! filesystem_info="$(run_sudo @tune2fs@ -l "$root_source")"; then |
There was a problem hiding this comment.
There is a critical bug in the require_sudo function (defined on lines 33-38) that prevents this entire block (and other sudo-dependent parts of the script) from executing when sudo is available.
In Bash, if a function does not end with an explicit return statement, its exit status is that of the last command executed. In require_sudo:
require_sudo() {
if [ "${#sudo_cmd[@]}" -eq 0 ]; then
echo "Warning: sudo not found, skipping k3s system setup" >&2
return 1
fi
}When sudo is available, the if condition [ "${#sudo_cmd[@]}" -eq 0 ] evaluates to false (exit status 1), the body is skipped, and the function exits. Since the [ test was the last command executed, the function returns 1.
As a result, require_sudo || return 0 on line 55 will always evaluate to true and return early, skipping the filesystem inspection entirely. Similarly, require_sudo || exit 0 on lines 84 and 92 will cause the script to exit prematurely.
To fix this, please add an explicit return 0 at the end of require_sudo.
There was a problem hiding this comment.
Fixed in 83bfbfb with an explicit success return and a focused regression assertion; the native Kyber activation-package build also succeeds.
| fi | ||
| # shellcheck disable=SC2016 | ||
| block_count="$(run_sudo @tune2fs@ -l "$root_source" 2>/dev/null | @awk@ -F: '/^Block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }')" | ||
| block_count="$(printf '%s\n' "$filesystem_info" | @awk@ -F: '/^Block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }')" |
There was a problem hiding this comment.
Since this script is executed with Bash (#!/usr/bin/env bash), you can use a here-string (<<<) instead of piping printf output to awk. This is more efficient as it avoids spawning an extra subshell/process for the pipeline.
| block_count="$(printf '%s\n' "$filesystem_info" | @awk@ -F: '/^Block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }')" | |
| block_count="$(@awk@ -F: '/^Block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }' <<< "$filesystem_info")" |
There was a problem hiding this comment.
Updated both parsers to Bash here-strings in 83bfbfb.
| block_count="$(printf '%s\n' "$filesystem_info" | @awk@ -F: '/^Block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }')" | ||
| # shellcheck disable=SC2016 | ||
| reserved_blocks="$(run_sudo @tune2fs@ -l "$root_source" 2>/dev/null | @awk@ -F: '/^Reserved block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }')" | ||
| reserved_blocks="$(printf '%s\n' "$filesystem_info" | @awk@ -F: '/^Reserved block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }')" |
There was a problem hiding this comment.
Similarly, you can use a here-string (<<<) here to avoid the pipeline and printf subshell.
| reserved_blocks="$(printf '%s\n' "$filesystem_info" | @awk@ -F: '/^Reserved block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }')" | |
| reserved_blocks="$(@awk@ -F: '/^Reserved block count:/ { gsub(/[[:space:]]/, "", $2); print $2 }' <<< "$filesystem_info")" |
There was a problem hiding this comment.
Updated the reserved-block parser to the same here-string form in 83bfbfb.
4539f19 to
83bfbfb
Compare
Mesa DescriptionTL;DRHardened and optimized K3s activation reserve setup by caching ext4 filesystem metadata, introducing robust error handling, explicitly documenting kubelet defaults, and tightening test specs. What changed?
Description generated by Mesa. Update settings |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found and verified against the latest diff
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="home-manager/services/k3s/activate.sh">
<violation number="1" location="home-manager/services/k3s/activate.sh:57">
P3: The new best-effort behavior is unverified: a future change could make an inspection or mutation failure abort activation again without CI detecting it. A focused shellspec fixture that stubs `tune2fs` should cover both failures and assert activation continues while emitting the warning.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| fi | ||
|
|
||
| require_sudo || return 0 | ||
| if ! filesystem_info="$(run_sudo @tune2fs@ -l "$root_source")"; then |
There was a problem hiding this comment.
P3: The new best-effort behavior is unverified: a future change could make an inspection or mutation failure abort activation again without CI detecting it. A focused shellspec fixture that stubs tune2fs should cover both failures and assert activation continues while emitting the warning.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At home-manager/services/k3s/activate.sh, line 56:
<comment>The new best-effort behavior is unverified: a future change could make an inspection or mutation failure abort activation again without CI detecting it. A focused shellspec fixture that stubs `tune2fs` should cover both failures and assert activation continues while emitting the warning.</comment>
<file context>
@@ -53,10 +53,14 @@ configure_root_ext4_reserve() {
fi
require_sudo || return 0
+ if ! filesystem_info="$(run_sudo @tune2fs@ -l "$root_source")"; then
+ echo "Warning: unable to inspect ext4 reserve on $root_source" >&2
+ return 0
</file context>
1 participant
Summary
Validation
shellcheck home-manager/services/k3s/activate.sh config/k3s/activate.shshellspec spec/k3s_service_activate_spec.sh spec/activate_k3s_spec.sh(31 examples, 0 failures)git diff --checkmake nix-format-checkFollow-up to #2126 for review findings that arrived as it auto-merged.
Summary by cubic
Make Kyber k3s activation keep the ext4 root reserve setup best-effort and consistent, and pin kubelet image GC thresholds. Improves reliability during activation and clarifies disk/IO pressure behavior.
tune2fs -lonce, parse a single snapshot, warn and skip on failures, set a 1% ext4 reserve when possible, and return success whensudois available.imageGCHighThresholdPercent: 85andimageGCLowThresholdPercent: 80, documented inkubelet.confto make the host headroom contract explicit./proc/pressure/ioto troubleshooting steps.require_sudoand tighten the reserve-policy assertion to match the exacttarget_reserved_percent=1line.Written for commit 83bfbfb. Summary will update on new commits.