rp-registry

Scopo

Il registro dei moduli e delle soluzioni: cosa esiste, di cosa è composta ogni soluzione
e i byte stessi. Risponde a due lettori che non condividono nient'altro. Ptah
richiede un indice e poi gli oggetti tramite digest, senza mai conoscere un nome e
verificando ogni byte ricevuto. Il portale e la chat pongono la domanda opposta —
quali soluzioni esistono, cosa apporterebbe questa, di cosa ha bisogno prima.

Entrambi risiedono su un unico servizio perché un catalogo che nomina moduli che
l'object store non contiene è proprio il problema che questo vuole prevenire, e ciò
può essere verificato solo dove entrambe le metà sono visibili.

Confine di responsabilità

rp-registry non tocca mai un cluster. Pubblica un catalogo e serve byte;
trasformare una selezione in una piattaforma in esecuzione è compito di lm-kubernetes,
che scrive risorse personalizzate Solution, mentre riconciliarle è compito di ptah.
Mantenere questa separazione significa che un unico registro può servire molti cluster
senza custodire credenziali per nessuno di essi.

Archiviazione

Due store, deliberatamente non di più.

objects è un unico KV store che contiene due tipi di valori sotto due prefissi:
i byte dei moduli tramite digest (obj) e i documenti delle soluzioni per layer e nome (sol).
Entrambi vengono letti per intero tramite una chiave esatta, quindi sono lo stesso tipo
di archiviazione usato due volte. KVStore distingue i dati binari dal JSON tramite
un'intestazione che scrive autonomamente, quindi qui nessuno dei due prefissi richiede
decodifica.

catalog è SQL, perché contiene la parte che cambia e quella che viene interrogata:
quale artefatto risolve attualmente in quale digest, in quale layer. I byte sono
immutabili e indirizzati tramite il contenuto, quindi non necessitano di una tabella;
i nomi cambiano a ogni pubblicazione e vengono richiesti per layer, per tipo e tra i layer.

La mappatura pubblicata non viene memorizzata. È un fold su layers e modules
calcolato su richiesta, e il suo digest è la revision. Memorizzarla significherebbe
mantenere una seconda copia della verità che diventa obsoleta esattamente quando una
pubblicazione è appena avvenuta e un cluster sta chiedendo perché non riesce a vederla.

Layer

Un layer è l'output di una build. converged pubblica i propri moduli, club pubblica
i propri e dichiara extends: ["converged"], e la mappatura che ogni consumatore legge
è composta da tutti loro — un layer di prodotto viene posizionato dopo la base da cui
si estende, così vince un modulo che sostituisce deliberatamente. L'ordine di
pubblicazione smette di essere rilevante e nessuna build può cancellare nomi che non
ha creato.

La pubblicazione sostituisce interamente un layer invece di unirlo: una pubblicazione
è l'intero output di quel layer, quindi un nome che la nuova build non produce più
deve scomparire. Un'unione lo lascerebbe puntare a byte che ormai nessuna build produce.

Servire i byte

ensureObjectCached restituisce una chiave Valkey, non l'oggetto. I byte vengono
materializzati nella cache con ambito e letti da lì dalla ui, che è lo stesso
passaggio di consegne usato dalla gallery per le immagini e per lo stesso motivo:
un modulo può raggiungere 2 MiB, e rispondere con il payload lo farebbe passare da
storage → ms → ui a ogni mancata cache, attraverso un canale destinato alle richieste.

Le due route utilizzate da un cluster — /registry/index.json e /registry/<digest> —
sono servite dall'host ui del club, non da questo servizio
(club/core/frontend/landing/src/ptah-registry.ts). ptah parla semplice HTTP e
nient'altro, quindi qualcosa con una superficie HTTP deve rispondere per lui, e questo
qualcosa è la ui; l'immagine base ne resta fuori, perché un prodotto senza un registro
non ha nulla da servire. Le route sono anonime, perché l'autenticità si basa sul
digest: ptah verifica ogni byte ricevuto rispetto al digest richiesto, quindi un
segreto condiviso aggiungerebbe qualcosa da distribuire e revocare senza aggiungere
una garanzia.

Un digest che nessun layer nomina non viene servito anche quando i byte sono archiviati.
Gli oggetti senza nome sono o rifiuti di una pubblicazione interrotta o qualcosa che un
chiamante ha indovinato, e servirli trasformerebbe questo sistema in un blob store aperto.

Limiti

Un oggetto è limitato a 2 MiB. I moduli reali sono dell'ordine di decine di kilobyte —
l'intero insieme di backend di converged è di circa 0,44 MiB compresso — e ptah rifiuta
qualsiasi cosa oltre 64 MiB, quindi questo limite è molto al di sotto di entrambi. Non
è un'ottimizzazione: il registro è destinato a contenere moduli della comunità, e un
upload delle dimensioni di un'immagine container significa che qualcuno ha pubblicato
l'artefatto sbagliato.

Gli oggetti vengono memorizzati esattamente come arrivano. Il registro non comprime né
decomprime: i bundle dei moduli sono brotli, le sorgenti dei workflow sono grezze perché
centimanus le esegue direttamente, e il digest copre i byte memorizzati in entrambi i
casi. Qualsiasi ricodifica romperebbe l'indirizzamento tramite contenuto proprio nell'unico
passaggio che esiste per proteggerlo.

Sorgente

modules/repositories/rp-registry