Beryl::Providers::Scaleway

Vrai si les credentials nécessaires sont disponibles (variables d'env, fichiers de config, agent local…). Ne lève jamais : un provider « indisponible » est simplement sauté par beryl init.

Reboot depuis le disque (inverse de request_rescue). Même signature de retour (task id).

Capabilities que ce provider expose (ADR-014). Valeurs connues :

:dns — gestion d'une zone DNS (records, reverse, refresh) :compute — hébergement de serveurs (rescue, boot_from_disk…) :object_storage — stockage objet compatible S3 (futur) :cdn — CDN (futur) :cert — certificats SSL (futur)

Un provider peut en avoir plusieurs (OVH = [:dns, :compute]). Beryl vérifie la capability avant d'appeler une méthode correspondante — si un dns_provider: hetzner est déclaré alors qu'Hetzner n'a pas :dns, une erreur explicite est levée à la résolution.

Par défaut vide : chaque sous-classe doit la définir.

Vrai si l'état status correspond à un terminal de succès ("done", "completed", etc. selon les providers).

État d'une task ("init", "doing", "done", "ovhError"…). Convention : si la task est en état terminal de succès, task_done? est vrai.

Variables d'environnement nécessaires pour que available? soit vrai et que les appels API marchent. Listées dans l'ordre où beryl init les demandera si le provider n'est pas configuré. Utilisé pour la configuration interactive + aide.

Détails affichés pendant beryl init : liste textuelle des permissions IAM à cocher dans la console Scaleway.

URL d'aide côté panel hébergeur où l'utilisateur génère les credentials (token d'API, secret key, etc.). Affichée avant le prompt interactif pour que l'opérateur ouvre sa page dans un autre onglet.

Nom humain pour affichage (ex: "OVHcloud", "Scaleway Elastic Metal").

Liste les clés SSH enregistrées côté panel de l'hébergeur, avec leur contenu public. beryl init utilise le contenu pour matcher avec les ~/.ssh/*.pub locaux — si une clé distante correspond à un fichier local (type + base64 identiques, le commentaire peut différer), on auto-détecte le mapping sans prompt.

Lève si les credentials sont présents mais l'API refuse.

Identifiant court et stable du provider (ex: "ovh", "scaleway"). Utilisé comme clé dans le registre, comme valeur de provider: dans le YAML d'un host, et comme nom dans les logs.

Vrai si ce provider héberge le serveur identifié par host_name. Conservé pour compat (ex: diagnostics). La résolution d'hôte n'en a plus besoin : elle passe par suffix-match et recherche dans les fichiers (voir Beryl::Config::Root#resolve). Cette méthode peut être utilisée par les sous-commandes qui veulent confirmer qu'un serveur existe bien chez le provider.

Demande un reboot en rescue mode côté panel. Le provider pose la clé SSH qu'il veut que beryl utilise pour se connecter. Retourne un identifiant de task (numérique OVH, ou UUID Scaleway) qu'on peut interroger avec compute_task_status.

Permissions IAM Scaleway requises par beryl. Contrairement à OVH, Scaleway ne permet pas de générer une API key depuis zéro via l'API (chicken-and-egg : il faut déjà une key pour en créer une). L'utilisateur doit donc créer la key manuellement dans la console, en cochant les permission_set_names ci-dessous.

Référence : https://www.scaleway.com/en/developers/api/iam/#permission-sets

Rend le champ YAML à écrire dans le groupe zone pour que beryl rescue/bootstrap sache quelle clé utiliser. Typiquement : OVH → { "ssh_key_name" => "<label>" } Scaleway → { "ssh_key_ids" => ["<uuid>"] } Le shape dépend du provider ; le bloc est injecté tel quel sous <provider>: dans le YAML. Utilisé par beryl init pour générer un groups/<zone>.yml exploitable.