Capability Registry — API set_capabilities() avec aliasing de set_services() #2

New Issue

shuss · 2026-06-06T14:35:54+02:00

shuss commented

2026-06-06 14:35:54 +02:00

Contexte

set_services() est l'API Rhai actuelle pour publier des services dans le registre. Elle doit être remplacée par set_capabilities() qui supporte le nouveau descripteur, tout en maintenant une compatibilité totale avec l'existant.

Comportement attendu

Nouvelle API primaire

// install_post.rhai
fn run(instance, context) {
    instance.set_capabilities([
        #{
            key: "smtp",
            type: "smtp",
            scope: "cluster",
            endpoint: #{
                fqdn: `${context.instance.appslug}.${context.instance.namespace}.svc`,
                port: 587,
                protocol: "starttls",
            },
            resource: #{
                kind: "Secret",
                name: `${context.instance.appslug}-smtp-creds`,
                namespace: context.instance.namespace,
            }
        },
    ]);
}

Aliasing de set_services() — rétrocompat transparente

set_services() continue de fonctionner. En interne, elle appelle set_capabilities() après remappage des champs :

Ancien champ	Nouveau champ
`service`	`endpoint`
`definition`	`resource`

type et scope sont laissés absents si non fournis (comportement préservé : accessible uniquement par key).

Stockage

Les capabilities publiées sont stockées dans la CRD existante (ou une nouvelle CRD VynilCapability si la structure actuelle ne suffit pas). Ce point est à trancher à l'implémentation.

Critère d'acceptance

set_capabilities() disponible en Rhai dans install_post.rhai
set_services() continue de fonctionner sans modification des packages existants
Le remappage service → endpoint / definition → resource est transparent
Les deux APIs alimentent le même registre

## Contexte `set_services()` est l'API Rhai actuelle pour publier des services dans le registre. Elle doit être remplacée par `set_capabilities()` qui supporte le nouveau descripteur, tout en maintenant une compatibilité totale avec l'existant. ## Comportement attendu ### Nouvelle API primaire ```rhai // install_post.rhai fn run(instance, context) { instance.set_capabilities([ #{ key: "smtp", type: "smtp", scope: "cluster", endpoint: #{ fqdn: `${context.instance.appslug}.${context.instance.namespace}.svc`, port: 587, protocol: "starttls", }, resource: #{ kind: "Secret", name: `${context.instance.appslug}-smtp-creds`, namespace: context.instance.namespace, } }, ]); } ``` ### Aliasing de set_services() — rétrocompat transparente `set_services()` continue de fonctionner. En interne, elle appelle `set_capabilities()` après remappage des champs : | Ancien champ | Nouveau champ | |-------------|---------------| | `service` | `endpoint` | | `definition`| `resource` | `type` et `scope` sont laissés absents si non fournis (comportement préservé : accessible uniquement par `key`). ## Stockage Les capabilities publiées sont stockées dans la CRD existante (ou une nouvelle CRD `VynilCapability` si la structure actuelle ne suffit pas). Ce point est à trancher à l'implémentation. ## Critère d'acceptance - `set_capabilities()` disponible en Rhai dans `install_post.rhai` - `set_services()` continue de fonctionner sans modification des packages existants - Le remappage `service → endpoint` / `definition → resource` est transparent - Les deux APIs alimentent le même registre

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

shuss added the Kind/Feature

Priority

High

2

labels 2026-06-06 14:35:54 +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

Priority

Low