Skip to content

Make RSC PyOxidizer builds offline#154

Open
Yash0270 wants to merge 1 commit into
facebookresearch:mainfrom
Yash0270:export-D108664638
Open

Make RSC PyOxidizer builds offline#154
Yash0270 wants to merge 1 commit into
facebookresearch:mainfrom
Yash0270:export-D108664638

Conversation

@Yash0270

Copy link
Copy Markdown
Contributor

Summary:
Stop cloud/meta_hpc_gcm Conveyor from depending on live egress inside the RSC systemd-nspawn container. The first failure was pip through fwdproxy, but PyOxidizer also fetched its CPython distribution, Rust toolchain/crates, and Cargo-generated metadata through paths that are not reliable in Sandcastle.

What's New

Component Description
ai_infra/rsc/build:download_pyoxidizer_wheels Builds a host-side PyOxidizer wheelhouse with PyOxidizer 0.24.0, the pinned CPython 3.10 python-build-standalone archive, and vendored Cargo crates extracted from PyOxidizer's pinned lockfile.
fair_infra/gcm:gcm_pyoxidizer_wheelhouse Extends the staged wheelhouse with GCM/healthchecks Python requirements before entering the RSC container.
build_gcm_common.sh Installs PyOxidizer from /var/out/python_wheels, forces pip offline, verifies the staged CPython and Cargo vendor artifacts exist, points PyOxidizer at the staged CPython archive, uses system Rust, and forces Cargo offline against the staged vendor dir.
build_gpu_burn_internal.sh Applies the same offline PyOxidizer, CPython, system Rust, Cargo vendor, and partial-stage checks to gpu_burn wrapper binaries.
fair_infra/gcm/Makefile Plumbs optional PyOxidizer args for system Rust and local CPython distribution without changing the default dev path.
fair_infra/gcm/pyoxidizer.bzl Uses a local PythonDistribution when provided and keeps the old default_python_distribution fallback.
ai_infra/rsc/compute:gpu_burn_build Applies the same offline PyOxidizer, CPython, and Cargo path to gpu_burn wrapper binaries.

Key Design Decisions

  • Stage network dependencies on the host before entering RSC: this removes the Sandcastle-only broken in-container fwdproxy path.
  • Keep fallback behavior for non-Buck/manual callers: if /var/out/python_wheels is absent, the scripts still use the previous fwdproxy path.
  • Use system Rust plus vendored crates: PyOxidizer's managed Rust bootstrap downloads from static.rust-lang.org, then Cargo downloads from crates.io. Both are now avoided.
  • Wrap only cargo init: Cargo 1.95 defaults new projects to edition 2024, but PyOxidizer 0.24's cargo_toml parser only supports up to 2021. The wrapper adds --edition 2021 only for init and delegates every other Cargo command to /usr/bin/cargo.
  • Keep Cargo state under /tmp: root-owned Cargo cache files under Buck OUT_DIR broke cleanup after failed container runs.
  • Use network_access instead of uses_sudo for wheelhouse genrules: these genrules only prefetch artifacts and do not need sudo.

Reviewed By: calebho

Differential Revision: D108664638

Summary:
Stop cloud/meta_hpc_gcm Conveyor from depending on live egress inside the RSC systemd-nspawn container. The first failure was pip through fwdproxy, but PyOxidizer also fetched its CPython distribution, Rust toolchain/crates, and Cargo-generated metadata through paths that are not reliable in Sandcastle.

## What's New
| Component | Description |
|-----------|-------------|
| ai_infra/rsc/build:download_pyoxidizer_wheels | Builds a host-side PyOxidizer wheelhouse with PyOxidizer 0.24.0, the pinned CPython 3.10 python-build-standalone archive, and vendored Cargo crates extracted from PyOxidizer's pinned lockfile. |
| fair_infra/gcm:gcm_pyoxidizer_wheelhouse | Extends the staged wheelhouse with GCM/healthchecks Python requirements before entering the RSC container. |
| build_gcm_common.sh | Installs PyOxidizer from /var/out/python_wheels, forces pip offline, verifies the staged CPython and Cargo vendor artifacts exist, points PyOxidizer at the staged CPython archive, uses system Rust, and forces Cargo offline against the staged vendor dir. |
| build_gpu_burn_internal.sh | Applies the same offline PyOxidizer, CPython, system Rust, Cargo vendor, and partial-stage checks to gpu_burn wrapper binaries. |
| fair_infra/gcm/Makefile | Plumbs optional PyOxidizer args for system Rust and local CPython distribution without changing the default dev path. |
| fair_infra/gcm/pyoxidizer.bzl | Uses a local PythonDistribution when provided and keeps the old default_python_distribution fallback. |
| ai_infra/rsc/compute:gpu_burn_build | Applies the same offline PyOxidizer, CPython, and Cargo path to gpu_burn wrapper binaries. |

## Key Design Decisions
- Stage network dependencies on the host before entering RSC: this removes the Sandcastle-only broken in-container fwdproxy path.
- Keep fallback behavior for non-Buck/manual callers: if /var/out/python_wheels is absent, the scripts still use the previous fwdproxy path.
- Use system Rust plus vendored crates: PyOxidizer's managed Rust bootstrap downloads from static.rust-lang.org, then Cargo downloads from crates.io. Both are now avoided.
- Wrap only `cargo init`: Cargo 1.95 defaults new projects to edition 2024, but PyOxidizer 0.24's cargo_toml parser only supports up to 2021. The wrapper adds `--edition 2021` only for init and delegates every other Cargo command to /usr/bin/cargo.
- Keep Cargo state under /tmp: root-owned Cargo cache files under Buck OUT_DIR broke cleanup after failed container runs.
- Use `network_access` instead of `uses_sudo` for wheelhouse genrules: these genrules only prefetch artifacts and do not need sudo.

Reviewed By: calebho

Differential Revision: D108664638
@meta-codesync

meta-codesync Bot commented Jun 16, 2026

Copy link
Copy Markdown

@Yash0270 has exported this pull request. If you are a Meta employee, you can view the originating Diff in D108664638.

@github-actions

Copy link
Copy Markdown

CI Commands

The following CI workflows run automatically on every push and pull request:

Workflow What it runs
GPU Cluster Monitoring Python CI lint, tests, typecheck, format, deb build, pyoxidizer builds
Go packages CI shelper tests, format, lint

The following commands can be used by maintainers to trigger additional tests that require access to secrets:

Command Description Requires approval?
/metaci tests Runs Meta internal integration tests (pytest) Yes — a maintainer must trigger the command and approve the deployment request
/metaci integration tests Same as above (alias) Yes

Note: Only repository maintainers (OWNER association) can trigger /metaci commands. After commenting the command, a maintainer must also navigate to the Actions tab and approve the deployment to the graph-api-access environment before the jobs will run. See the approval guidelines for what to approve or reject.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant