-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
RFC 0001: Pulp Content Management
RFC Document: docs/rfcs/0001-pulp-content-management.md (in tinyland.dev repo)
Status: Draft
Author: xoxd
Summary
Deploy a Pulp instance as a unified content management and caching proxy for the GloriousFlywheel CI runner fleet. Pulp fronts npm, PyPI, container registries, and Nix binary caches behind a single self-hosted service.
Motivation
- Docker Hub rate limits (429) hit CI runners and K8s pod pulls
- npm publishing rate limits block bulk publishing runs
- Nix binary cache (Attic) is single-purpose — no shared infra
- GitLab Dependency Proxy is container-only with limited visibility
- Build reproducibility depends on external registries being available
Content Types
| Type | Plugin | Replaces |
|---|---|---|
| Container images | pulp_container |
GitLab Dependency Proxy, manual skopeo mirrors |
| npm packages | pulp_npm |
Direct npmjs.com access |
| Python packages | pulp_python |
Direct PyPI access |
| RPM/DNF | pulp_rpm |
Direct Rocky Linux repos |
| Nix cache | pulp_file |
Attic |
Implementation Phases
- Phase 1 (Week 1): Container cache — Docker Hub pull-through, replace manual mirrors
- Phase 2 (Week 2): npm cache — npmjs.com pull-through, absorb 429 rate limits
- Phase 3 (Week 3): Python + RPM caches
- Phase 4 (Week 4): Nix cache evaluation (Pulp vs Attic)
Resource Estimate
~650m CPU, 1.7Gi RAM, 12Gi storage on existing Civo K8s cluster.
Open Questions
- Should Pulp replace Attic for Nix binary caching, or coexist?
- What retention policy for pull-through caches?
- Should developer workstations also use Pulp, or only CI?
See the full RFC in docs/rfcs/0001-pulp-content-management.md.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels