fix: serve fls binary from exporter instead of downloading from GitHub#840
fix: serve fls binary from exporter instead of downloading from GitHub#840bennyz wants to merge 1 commit into
Conversation
Serve the fls binary already installed in the exporter container via its HTTP server, Users can still override with --fls-version or --fls-binary-url. This would help to avoid scenarios in which github is not available for example Signed-off-by: Benny Zlotnik <bzlotnik@redhat.com> Assisted-by: claude-opus-4.6
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@python/packages/jumpstarter-driver-flashers/jumpstarter_driver_flashers/driver.py`:
- Around line 85-86: The fls binary missing check in driver.py currently raises
FileNotFoundError, which the client treats as retryable and sends through the
full backoff loop. Update the error path in the fls_path existence check to
raise or map to a non-retryable exception, and ensure client.py’s
_categorize_exception recognizes that case as terminal so a permanently missing
binary fails immediately instead of retrying.
- Around line 84-87: The `fls` export step in `driver.py` should not assume the
served binary is always compatible with the DUT. Update the `fls_path` copy
logic in the relevant driver method to verify the exporter binary architecture
before calling `self.http.storage.copy_exporter_file`, and either pin the
exporter download to the DUT’s `aarch64` binary or raise a clear mismatch error
when the exporter is running on a different arch such as `amd64`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9765e254-4b9f-4088-8c73-088927dcc321
📒 Files selected for processing (2)
python/packages/jumpstarter-driver-flashers/jumpstarter_driver_flashers/client.pypython/packages/jumpstarter-driver-flashers/jumpstarter_driver_flashers/driver.py
| fls_path = Path("/usr/local/bin/fls") | ||
| if not fls_path.exists(): | ||
| raise FileNotFoundError("fls binary not found at /usr/local/bin/fls") | ||
| await self.http.storage.copy_exporter_file(fls_path, "fls") |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Inspect how /usr/local/bin/fls gets into the exporter image and its target arch.
fd -t f 'Dockerfile|Containerfile' | xargs -r rg -n -i 'fls'
rg -nP 'fls' --glob '*.Dockerfile' --glob '*Dockerfile*' --glob '*.containerfile' -C2Repository: jumpstarter-dev/jumpstarter
Length of output: 546
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the container build around fls and how ARCH is derived.
cat -n python/Containerfile | sed -n '1,120p'
# Inspect the driver code around setup_fls_binary.
cat -n python/packages/jumpstarter-driver-flashers/jumpstarter_driver_flashers/driver.py | sed -n '60,110p'Repository: jumpstarter-dev/jumpstarter
Length of output: 4085
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find where FLS_ARCH/ARCH is set or passed into the container build.
rg -n --hidden --glob '!**/.git/**' '\bARCH\b|\bFLS_VERSION\b|\bFLS_SUFFIX\b|fls-\$\{ARCH\}' pythonRepository: jumpstarter-dev/jumpstarter
Length of output: 873
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look for any build/runtime docs mentioning the exporter image architecture.
rg -n --hidden --glob '!**/.git/**' -i 'exporter.*arch|arch.*exporter|fls binary|jumpstarter-driver-flashers|jumpstarter_driver_flashers' .Repository: jumpstarter-dev/jumpstarter
Length of output: 7670
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the client path that decides between downloading and serving the exporter binary.
sed -n '680,720p' python/packages/jumpstarter-driver-flashers/jumpstarter_driver_flashers/client.pyRepository: jumpstarter-dev/jumpstarter
Length of output: 2291
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the client path that decides between downloading and serving the exporter binary.
sed -n '680,720p' python/packages/jumpstarter-driver-flashers/jumpstarter_driver_flashers/client.pyRepository: jumpstarter-dev/jumpstarter
Length of output: 2291
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look for exporter-image or flasher-driver build docs that pin the image arch/platform.
rg -n --hidden --glob '!**/.git/**' -i 'platform=.*aarch64|aarch64.*exporter|exporter.*aarch64|fls.*aarch64|buildx|docker build|podman build' python .githubRepository: jumpstarter-dev/jumpstarter
Length of output: 1606
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the fls helper and any docs around binary selection.
sed -n '1,220p' python/packages/jumpstarter/jumpstarter/common/fls.pyRepository: jumpstarter-dev/jumpstarter
Length of output: 4407
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect how the exporter image is built and whether it is platform-aware.
sed -n '140,230p' .github/workflows/build-images.yamlRepository: jumpstarter-dev/jumpstarter
Length of output: 4158
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect whether the flashers driver has any explicit platform constraints in docs/config.
sed -n '1,220p' python/packages/jumpstarter-driver-flashers/README.mdRepository: jumpstarter-dev/jumpstarter
Length of output: 10651
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '140,230p' .github/workflows/build-images.yamlRepository: jumpstarter-dev/jumpstarter
Length of output: 4158
Pin the exporter-served fls to the DUT arch. The exporter image installs fls using uname -m, but the DUT path always expects the aarch64 binary. If the exporter runs on amd64, the served binary will be incompatible; pin the exporter download or fail fast on mismatch.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@python/packages/jumpstarter-driver-flashers/jumpstarter_driver_flashers/driver.py`
around lines 84 - 87, The `fls` export step in `driver.py` should not assume the
served binary is always compatible with the DUT. Update the `fls_path` copy
logic in the relevant driver method to verify the exporter binary architecture
before calling `self.http.storage.copy_exporter_file`, and either pin the
exporter download to the DUT’s `aarch64` binary or raise a clear mismatch error
when the exporter is running on a different arch such as `amd64`.
| if not fls_path.exists(): | ||
| raise FileNotFoundError("fls binary not found at /usr/local/bin/fls") |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
FileNotFoundError here will be retried instead of failing fast.
When the binary is absent this raises FileNotFoundError, which propagates to the client retry loop. _categorize_exception treats unknown exceptions as retryable, so a permanently-missing binary triggers the full backoff/retry cycle (Lines 226-271 in client.py) before failing. Since this is a deterministic, non-retryable condition, consider raising a non-retryable error type (or having the client categorize it as such) so it fails immediately.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@python/packages/jumpstarter-driver-flashers/jumpstarter_driver_flashers/driver.py`
around lines 85 - 86, The fls binary missing check in driver.py currently raises
FileNotFoundError, which the client treats as retryable and sends through the
full backoff loop. Update the error path in the fls_path existence check to
raise or map to a non-retryable exception, and ensure client.py’s
_categorize_exception recognizes that case as terminal so a permanently missing
binary fails immediately instead of retrying.
Serve the fls binary already installed in the exporter container via its HTTP server, Users can still override with --fls-version or --fls-binary-url.
This would help to avoid scenarios in which github is not available for example