Beryl::Providers::Ovh
Inherits Beryl::ComputeProvider < Beryl::DnsProvider < Beryl::Provider < Reference < Object
Provider OVHcloud pour beryl. Encapsule la détection des credentials
(via Beryl::CLI::Credentials.ovh_client) et le listing des clés
SSH enregistrées dans le compte.
Le client OVH est injectable via le constructeur pour les tests.
En production, on laisse le défaut nil et client résout à
la demande via Credentials.ovh_client.
Constructors
Instance methods
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).
Génère la consumer key OVH si absente (ou si force_regen).
Utilise POST /auth/credential du shard ovh-api 0.4.0 avec
la liste exacte des access rules de required_access_rules.
Flux utilisateur :
- Requête API → retourne une URL de validation
- Beryl ouvre le navigateur (macOS
open, Linuxxdg-open) - L'utilisateur clique « autoriser » dans OVH
- Beryl attend une confirmation (Entrée)
- La consumer_key est stockée dans env
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 : beryl génère la consumer
key automatiquement via POST /auth/credential, l'opérateur n'a
donc qu'à cocher « autoriser » dans le navigateur. Les routes
listées ci-dessous sont injectées automatiquement par le hook
bootstrap_credentials_if_needed — documentation uniquement.
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.
Enregistre (ou met à jour) un record DNS. Idempotent : si le record existe déjà avec la même valeur, no-op.
zone → nom de la zone (ex: "aloli.net")
field_type → type DNS ("A", "AAAA", "CNAME", "TXT"…)
sub_domain → sous-partie ("loulou" ou "" pour le root)
target → valeur du record (IP, FQDN, …)
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.
Déclenche un refresh de la zone côté provider (nécessaire chez OVH pour propager un record fraîchement ajouté).
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.
Routes OVH que beryl appelle. Injectées dans la consumer_key
au moment de la création via POST /auth/credential. Les *
sont des wildcards supportés par OVH (pattern « tout sous ce
préfixe avec un / »). ATTENTION : /me/sshKey/* NE matche PAS
/me/sshKey nu (endpoint de liste). Il faut les deux :
/me/sshKey→ GET pour lister les noms de clés/me/sshKey/*→ GET pour récupérer le détail d'une clé Même logique pour/dedicated/serveret/domain/zone.
Change le nom d'affichage d'une ressource côté panel. Pour OVH,
c'est le displayName du serveur dédié. Pour Gandi ou d'autres
qui n'ont pas cette notion, no-op silencieux.
Pose (ou met à jour) le reverse DNS d'une IP. reverse est un
FQDN (avec ou sans point final).