Capability Registry — pré-alimentation de context.capabilities.* avant le rendu #4

New Issue

shuss · 2026-06-06T14:36:19+02:00

shuss commented

2026-06-06 14:36:19 +02:00

Contexte

Aujourd'hui, les packages doivent appeler resolv_service dans context_extra.rhai pour découvrir ce qui est disponible. L'objectif est que vynil alimente automatiquement context.capabilities avant tout rendu, de façon à ce que les packages n'aient plus à faire de découverte eux-mêmes.

Comportement attendu

Avant d'appeler context_extra.rhai et avant tout rendu de template, vynil interroge le registre de capabilities pour toutes les capabilities visibles depuis le namespace courant (en appliquant les règles de scope) et les injecte dans le contexte :

context.capabilities["ca"]   = #{available: true, key: "internal-ca", resource: #{...}}
context.capabilities["smtp"] = #{available: true, key: "smtp", endpoint: #{...}}
context.capabilities["mcp"]  = [   // array si plusieurs capabilities du même type
    #{available: true, key: "mcp-gitea", endpoint: #{...}},
    #{available: true, key: "mcp-grafana", endpoint: #{...}},
]

Règles de structure

Si une seule capability du type : objet direct
Si plusieurs capabilities du même type : array
Si aucune : clé absente (ou #{available: false} — à trancher à l'implémentation)

Impact sur context_extra.rhai

Les packages n'ont plus à appeler resolv_service pour la découverte. context_extra.rhai se réduit à la logique métier propre au package.

Exemple de migration :

// Avant
let smtp = svc::get_tenant(context, ["smtp-relay", "smtp"]);
if smtp != () { extra.smtp_host = smtp.fqdn; }

// Après (context_extra.rhai)
// Rien — extra.smtp_host est alimenté depuis context.capabilities["smtp"] directement dans le template

Compatibilité avec context_extra.rhai existant

context_extra.rhai peut toujours appeler resolv_service — ce n'est pas une rupture. La pré-alimentation est additive : elle ajoute context.capabilities sans retirer les fonctions existantes.

Critère d'acceptance

context.capabilities est disponible dans les templates HBS et dans context_extra.rhai
Le filtrage de scope est appliqué (identique à get_by_type())
Les capabilities sans type (ancien format) n'apparaissent pas dans context.capabilities mais restent accessibles via resolv_service
Les tests de template existants (make template) continuent de fonctionner (capabilities vides si cluster non connecté)

## Contexte Aujourd'hui, les packages doivent appeler `resolv_service` dans `context_extra.rhai` pour découvrir ce qui est disponible. L'objectif est que vynil alimente automatiquement `context.capabilities` avant tout rendu, de façon à ce que les packages n'aient plus à faire de découverte eux-mêmes. ## Comportement attendu Avant d'appeler `context_extra.rhai` et avant tout rendu de template, vynil interroge le registre de capabilities pour toutes les capabilities visibles depuis le namespace courant (en appliquant les règles de scope) et les injecte dans le contexte : ``` context.capabilities["ca"] = #{available: true, key: "internal-ca", resource: #{...}} context.capabilities["smtp"] = #{available: true, key: "smtp", endpoint: #{...}} context.capabilities["mcp"] = [ // array si plusieurs capabilities du même type #{available: true, key: "mcp-gitea", endpoint: #{...}}, #{available: true, key: "mcp-grafana", endpoint: #{...}}, ] ``` ### Règles de structure - Si **une seule** capability du type : objet direct - Si **plusieurs** capabilities du même type : array - Si **aucune** : clé absente (ou `#{available: false}` — à trancher à l'implémentation) ### Impact sur context_extra.rhai Les packages n'ont plus à appeler `resolv_service` pour la découverte. `context_extra.rhai` se réduit à la logique métier propre au package. Exemple de migration : ```rhai // Avant let smtp = svc::get_tenant(context, ["smtp-relay", "smtp"]); if smtp != () { extra.smtp_host = smtp.fqdn; } // Après (context_extra.rhai) // Rien — extra.smtp_host est alimenté depuis context.capabilities["smtp"] directement dans le template ``` ## Compatibilité avec context_extra.rhai existant `context_extra.rhai` peut toujours appeler `resolv_service` — ce n'est pas une rupture. La pré-alimentation est additive : elle ajoute `context.capabilities` sans retirer les fonctions existantes. ## Critère d'acceptance - `context.capabilities` est disponible dans les templates HBS et dans `context_extra.rhai` - Le filtrage de scope est appliqué (identique à `get_by_type()`) - Les capabilities sans `type` (ancien format) n'apparaissent pas dans `context.capabilities` mais restent accessibles via `resolv_service` - Les tests de template existants (`make template`) continuent de fonctionner (capabilities vides si cluster non connecté)

shuss added this to the Capability Registry v1 milestone 2026-06-06 14:36:19 +02:00

shuss added the Kind/Feature

Priority

High

2

labels 2026-06-06 14:36:19 +02:00

xmortelette referenced this issue

2026-06-10 19:43:53 +02:00

lint:packages — variables/schémas incorrects non détectés à la validation #7

shuss added

and removed

labels 2026-06-12 10:30:41 +02:00

xmortelette commented

2026-06-12 11:24:41 +02:00

Observation tirée de l'analyse de paquets en production, qui confirme l'intérêt de cette issue : environ deux tiers des paquets matures ont un context_extra.rhai, et son contenu se partage entre découverte (lookups resolv_service, tests de présence de CRD via context.cluster.crds.contains(...) pour activer le monitoring, etc.) et dérivation (réplicas selon le mode HA, sélection de classe de stockage, tailles depuis resources). La pré-alimentation de context.capabilities éliminera la moitié « découverte » ; la dérivation restera dans context_extra, ce qui est sain.

Deux points d'implémentation à verrouiller :

Rendu hors cluster : le critère « capabilities vides si cluster non connecté » gagnerait à être précisé — context.capabilities devrait être toujours présent (map vide le cas échéant), pour que templates et hooks puissent tester la disponibilité sans try/catch ni divergence entre test local et cluster.
Présence de CRD comme capability : le pattern le plus fréquent dans les context_extra actuels est le test direct de context.cluster.crds. Si les paquets système publiaient ces capacités dans le registre (ex. type: prometheus publié par la stack de monitoring), ce pattern migrerait aussi vers context.capabilities — à garder en tête pour le vocabulaire de type de #1, sans en faire un prérequis.

Analyse et rédaction : Claude (assistant IA), publié via le compte de Xavier.

Observation tirée de l'analyse de paquets en production, qui confirme l'intérêt de cette issue : environ deux tiers des paquets matures ont un `context_extra.rhai`, et son contenu se partage entre **découverte** (lookups `resolv_service`, tests de présence de CRD via `context.cluster.crds.contains(...)` pour activer le monitoring, etc.) et **dérivation** (réplicas selon le mode HA, sélection de classe de stockage, tailles depuis `resources`). La pré-alimentation de `context.capabilities` éliminera la moitié « découverte » ; la dérivation restera dans `context_extra`, ce qui est sain. Deux points d'implémentation à verrouiller : 1. **Rendu hors cluster** : le critère « capabilities vides si cluster non connecté » gagnerait à être précisé — `context.capabilities` devrait être *toujours présent* (map vide le cas échéant), pour que templates et hooks puissent tester la disponibilité sans try/catch ni divergence entre test local et cluster. 2. **Présence de CRD comme capability** : le pattern le plus fréquent dans les `context_extra` actuels est le test direct de `context.cluster.crds`. Si les paquets système publiaient ces capacités dans le registre (ex. `type: prometheus` publié par la stack de monitoring), ce pattern migrerait aussi vers `context.capabilities` — à garder en tête pour le vocabulaire de `type` de #1, sans en faire un prérequis. --- *Analyse et rédaction : Claude (assistant IA), publié via le compte de Xavier.*

shuss added the

Status

Blocked

1

label 2026-06-12 17:43:43 +02:00

shuss commented

2026-06-12 17:49:16 +02:00

La série "Capability Registry" bien qu'intéressante est franchement mal cablée au final. C'est le résultat d'une conversation, mais l'analyse était profondément incomplète au départ et au final bien trop calqué sur la solution actuelle.

Et cette stratégie ne permet pas, au final et avec un peu de recul, de répondre au besoin de l'évolution prévue. On cherches à construire un système d'auto-configuration complet du type .well-known. La stratégie ici est implémenté comme un breaking change alors qu'au fond ce n'est qu'une amélioration mineur du système actuel. En soit breaking et avec un intérêt limité, c'est un gros non de ma part.

Si on va dans la stratégie breaking, on va jusqu'au bout : on fait un vrai redesign, pas juste un léger patch sur un système bancal en le présentant comme une révolution : ce n'est pas une révolution d'ajouter 3 champs texte, ca ne mérite clairement pas tous ca.

La série "Capability Registry" bien qu'intéressante est franchement mal cablée au final. C'est le résultat d'une conversation, mais l'analyse était profondément incomplète au départ et au final bien trop calqué sur la solution actuelle. Et cette stratégie ne permet pas, au final et avec un peu de recul, de répondre au besoin de l'évolution prévue. On cherches à construire un système d'auto-configuration complet du type .well-known. La stratégie ici est implémenté comme un breaking change alors qu'au fond ce n'est qu'une amélioration mineur du système actuel. En soit breaking et avec un intérêt limité, c'est un gros *non* de ma part. Si on va dans la stratégie breaking, on va jusqu'au bout : on fait un vrai redesign, pas juste un léger patch sur un système bancal en le présentant comme une révolution : ce n'est pas une révolution d'ajouter 3 champs texte, ca ne mérite clairement pas tous ca.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: shuss/vynil#4