Beryl::Provider

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.

Hook appelé par beryl init après que les variables de base (app key, secret, etc.) sont présentes dans env. Permet au provider de compléter les credentials via un flux spécifique (ex: OVH — générer une consumer key via POST /auth/credential avec la liste des access rules exactes).

Le hook doit :

• retourner env éventuellement enrichi de nouvelles paires clé/valeur (ex: OVH_CONSUMER_KEY)
• être IDEMPOTENT : si la credential dérivée est déjà là et valide, et que force_regen est false, ne rien faire.
• respecter interactive : en non-interactif, ne pas prompter et lever explicitement si une saisie était indispensable.

Par défaut : no-op (Scaleway n'a pas d'auto-gen, il se contente de credentials_help_details pour indiquer quoi cocher à la main).

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.

Raccourci : provider.capable_of?(:dns).

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 d'aide supplémentaires à afficher pendant beryl init. Typiquement la liste exhaustive des permissions/routes que beryl va appeler, pour que l'opérateur puisse les cocher dans le formulaire du panel. Retourne nil si pas de détails particuliers.

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").

Vrai si le provider est implémenté dans le build courant de beryl. Utile pour beryl init : si l'utilisateur demande un DNS provider qu'on ne sait pas pilote, beryl l'avertit clairement plutôt que d'échouer silencieusement plus tard.

Par défaut : true — une classe Provider qui existe dans ce build est implémentée. Un provider « stub » (placeholder pour un futur shard) peut retourner false.

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.

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.