Package Cache on Porch Documentation

Cache Design

Mon, 01 Jan 0001 00:00:00 +0000

Cache Interface

The Package Cache provides a unified interface that abstracts the underlying storage mechanism. Both the CR Cache and DB Cache implementations conform to this common interface, allowing the CaDEngine to work with either implementation without knowing which is in use.

Repository Operations: Open repository connections from Repository CR specifications, close repositories and clean up resources, retrieve list of all open repositories, get specific repository by key, update repository metadata, and check repository connectivity.

Custom Resource Cache

Mon, 01 Jan 0001 00:00:00 +0000

Overview

The Custom Resource (CR) Cache is the default cache implementation in Porch. It stores package metadata using Kubernetes Custom Resources while keeping repository data in memory. This implementation is designed for standard Porch deployments where Kubernetes etcd provides sufficient storage and performance.

Key characteristics: The CR Cache is the default implementation when no cache type is explicitly configured. It uses hybrid storage (an in-memory repository cache plus CR-based metadata storage) and is RDBMS-independent: no RDBMS such as PostgreSQL is required, because it leverages the Kubernetes API, etcd, and Git for persistence. It is suitable for small to medium deployments with moderate package counts and has no external dependencies beyond a Kubernetes cluster. It interacts with Git at every stage of the package revision lifecycle for persistence.

Database Cache

Mon, 01 Jan 0001 00:00:00 +0000

Overview

The Database (DB) Cache is an alternative cache implementation in Porch designed for larger deployments. It stores both package metadata and repository data in a PostgreSQL database rather than in memory or Kubernetes Custom Resources. This implementation provides better scalability and persistence characteristics for production environments with high package counts.

Key characteristics: The DB Cache is the alternative implementation, used when it is explicitly configured with database connection details. All repository, package, and package revision data is stored in PostgreSQL, which requires an external PostgreSQL database instance. It is suitable for large deployments with thousands of packages and package revisions, and it survives Porch server restarts without re-fetching from Git. By default, it interacts with Git only during publish and sync (pull). With --db-push-drafts-to-git, draft and proposed revisions are also pushed to Git during the sync.

Cache Interactions

Mon, 01 Jan 0001 00:00:00 +0000

Overview

The Package Cache acts as an intermediary layer that coordinates between the CaDEngine, Repository Adapters, and external Git repositories. It provides caching, synchronization, and change notification services while maintaining a clean separation of concerns.

High-Level Architecture

┌─────────────────────────────────────────────────────────┐
│ Package Cache Layer │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────┐ │
│ │ CaDEngine │ ───> │ Cache │ ───> │ Repo │ │
│ │ Requests │ │ Operations │ │Adapt │ │
│ │ │ │ │ │ ers │ │
│ └──────────────┘ └──────────────┘ └──────┘ │
│ ↑ │ │ │
│ │ ↓ ↓ │
│ │ ┌──────────────┐ ┌──────┐ │
│ └──────────────│ Watcher │ │ Git │ │
│ │ Notifier │ │Repos │ │
│ └──────────────┘ └──────┘ │
└─────────────────────────────────────────────────────────┘

Repository Adapter Integration

The cache wraps repository adapters to provide caching and synchronization services: