Skip to content

RFC: Pulp Content Management for GloriousFlywheel CI #66

@Jesssullivan

Description

@Jesssullivan

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

  1. Phase 1 (Week 1): Container cache — Docker Hub pull-through, replace manual mirrors
  2. Phase 2 (Week 2): npm cache — npmjs.com pull-through, absorb 429 rate limits
  3. Phase 3 (Week 3): Python + RPM caches
  4. 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

  1. Should Pulp replace Attic for Nix binary caching, or coexist?
  2. What retention policy for pull-through caches?
  3. Should developer workstations also use Pulp, or only CI?

See the full RFC in docs/rfcs/0001-pulp-content-management.md.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions