Migrations de la base de la passerelle

Cette page est produite depuis les fichiers de gateway-db/migrations : elle ne peut pas décrire une migration qui n’existe pas, ni en oublier une qui existe.

Les 32 migrations

Elles s’appliquent dans l’ordre de ce tableau, qui est celui de leurs numéros.

Migration	Ce qu’elle fait
000-initial	ligne de base, l’état d’avant la première migration, défauts compris
001-endpoints	la table des points d’appel, un identifiant sur les fournisseurs, et le point d’appel dans le journal des requêtes
002-endpoint-enabled	un point d’appel peut être désactivé sans être supprimé
003-model-table	la table des modèles, à laquelle les points d’appel se rattachent
004-plans	la table des plans, et le plan auquel un compte appartient
005-convertion-rate	la table des taux de conversion
006-plans-max-cost-euro	le plafond d’un plan s’exprime en euros et non plus en crédits
007-plans-max-cost-euro-numeric	aligner le type de plans.max_cost_euro sur init.sql
008-provider-base-url-v1	versionner l’URL de base des fournisseurs de référence
009-providers-slug-constraint-name	aligner le nom de la contrainte d’unicité de providers.slug
010-retirer-les-cles-par-defaut	retirer les comptes porteurs d’une clé d’API publiée dans le dépôt
011-plans-plafond-illimite	rendre le plafond d’un plan facultatif, et semer le plan administrateur
012-attributions-de-roles	porter l’attribution des quatre rôles de §5.3 à des sujets
013-journal-des-decisions-et-sessions	le journal des décisions d’autorisation, et les sessions d’identité
014-politiques-d-autorisation	porter la politique d’autorisation détenue par le serveur
015-hacher-les-cles-api	ne plus stocker les clés d’API, seulement leur condensat
016-revocation-des-sujets	la liste de révocation des sujets
017-journal-des-actes-d-administration	le journal des actes d’administration
018-retirer-les-fournisseurs-semes	retirer les deux fournisseurs d’inférence semés par défaut
019-installation-de-politique-journalisee	l’installation d’une politique devient un acte d’administration journalisé
020-annonce-de-l-execution-agentique	ce que la passerelle annonce de son exécution agentique
021-named-access-keys	une clé d’accès devient un objet, nommé et révocable seul
022-identifiant-de-ligne-de-facturation	chaque ligne de facturation porte l’identifiant du relais qui l’a produite
023-roles-de-service-au-moindre-privilege	un rôle PostgreSQL par service, au moindre privilège
024-organization-policy	the gateway becomes the emitter of an organization’s policy (#395)
025-gateway-reads-authorization-decisions	the gateway may read the authorization journal, so the license module can rebuild its seat counter at startup
025-politique-d-organisation-depuis-la-console	installing an organization policy becomes an administrative act with a proven author
026-comptage-d-usage-dans-le-couloir-d-audit	la passerelle compte ce qu’elle relaie, dans le couloir d’audit
027-month-spend-index-on-request-logs	the month’s spend of one account, without reading the whole journal (#207)
028-agent-acts	the acts of the agent, remitted by the workstations (first slice of #763)
029-agent-acts-on-conflict-reads	the gateway reads agent_acts, because ON CONFLICT does (#763, first slice)
030-agent-session-revocations	an administrator revokes one agent session

Le jalon à poser sur une base qui existe déjà

Le script de migration tient un registre des migrations appliquées. Une base créée avant que ce registre n’existe, ou créée directement par le fichier d’installation gateway-db/init.sql, n’en a pas : il faut lui dire où elle en est, faute de quoi le script rejouerait depuis le début.

C’est ce que fait ./migrate.sh --baseline <numéro>, qui marque comme appliquées toutes les migrations jusqu’à ce numéro sans les exécuter.

Pour une base créée par le fichier d’installation, le jalon est 030, le numéro de la dernière migration de ce tableau. Le fichier d’installation crée en effet le schéma complet, à jour : rejouer les migrations sur elle échouerait, et poser un jalon plus bas ferait rejouer des migrations déjà contenues dans le schéma.

Un jalon posé trop loin ne produit aucune erreur : il marque comme appliquées des migrations qui ne l’ont jamais été. Sur une base réelle, cela laisse par exemple des clés d’API en clair dans une base que tout le reste du système croit converties. Le jalon ne se devine pas : il se lit dans le tableau ci-dessus.