provider-ovh 2.23.0 : load balancers OVHcloud, snapshots d'instances et 14 autres ressources

À retenir

• provider-ovh 2.23.0 fait passer le provider Terraform OVHcloud amont de la 2.19.0 à la 2.23.0, soit quatre versions amont, et ajoute 16 ressources managées dans les groupes d’API cluster et namespaced.
• L’ajout principal est la nouvelle API load balancer cloud : cinq kinds qui se référencent entre eux, pour déclarer un load balancer complet dans un seul manifeste.
• Aucune rupture pour les manifestes. Seul le code Go qui importe les types générés doit être adapté, pour deux renommages dans le groupe cloud.

La version 2.23.0 de provider-ovh, notre provider Crossplane pour OVHcloud, est sortie le 26 octobre 2026. Elle passe du provider Terraform OVHcloud 2.19.0 à la 2.23.0 et porte le provider à 184 ressources managées par scope d’API et 373 CRD, contre 168 et 341 auparavant.

La 2.19.1 changeait la manière dont le provider parle à OVHcloud sans toucher à la liste des ressources. La 2.23.0 fait l’inverse : l’architecture ne bouge pas, la liste s’allonge. C’est pour cela qu’elle n’a pas de section migration.

Les nouveautés : 16 ressources, dans les deux scopes d’API

Chaque nouveau kind est généré dans les groupes cluster *.ovh.edixos.io et dans les groupes namespaced *.ovh.m.edixos.io.

Tous utilisent comme external-name l’identifiant renvoyé par l’API OVHcloud.

La nouvelle API load balancer, en un seul manifeste

Les cinq kinds Loadbalancer* encapsulent les ressources load balancer ajoutées en amont dans la 2.21.0. Côté Crossplane, l’intérêt tient aux références. Les ressources amont se lient entre elles par identifiant, et provider-ovh 2.23.0 permet de résoudre chacun de ces identifiants par référence ou par sélecteur :

• loadbalancerId sur le listener, le pool et le membre de pool se résout vers un Loadbalancer.
• poolId sur un membre de pool, et defaultPoolId sur un listener, se résolvent vers un LoadbalancerPool.
• listenerId et redirectPoolId sur une politique L7 se résolvent vers un listener et un pool.

Plus besoin, donc, de copier l’identifiant d’un load balancer depuis status.atProvider pour le coller dans l’objet suivant. Crossplane attend que le load balancer expose son identifiant, le renseigne, et continue :

apiVersion: cloud.ovh.m.edixos.io/v1alpha1
kind: Loadbalancer
metadata:
  name: web
  namespace: team-a
spec:
  forProvider:
    serviceName: <public cloud project ID>
    region: GRA11
    name: web
    flavorName: small
    network:
      id: <private network ID>
      subnetId: <subnet ID>
---
apiVersion: cloud.ovh.m.edixos.io/v1alpha1
kind: LoadbalancerPool
metadata:
  name: web
  namespace: team-a
spec:
  forProvider:
    serviceName: <public cloud project ID>
    loadbalancerIdRef:
      name: web
    name: web
    protocol: HTTP
    algorithm: ROUND_ROBIN
    healthMonitor:
      type: HTTP
      urlPath: /healthz
      delay: 5
      timeout: 3
---
apiVersion: cloud.ovh.m.edixos.io/v1alpha1
kind: LoadbalancerPoolMember
metadata:
  name: web-0
  namespace: team-a
spec:
  forProvider:
    serviceName: <public cloud project ID>
    loadbalancerIdRef:
      name: web
    poolIdRef:
      name: web
    address: 10.0.0.10
    protocolPort: 8080
---
apiVersion: cloud.ovh.m.edixos.io/v1alpha1
kind: LoadbalancerListener
metadata:
  name: web-http
  namespace: team-a
spec:
  forProvider:
    serviceName: <public cloud project ID>
    loadbalancerIdRef:
      name: web
    defaultPoolIdRef:
      name: web
    name: web-http
    protocol: HTTP
    protocolPort: 80

Quatre objets, un seul kubectl apply, et aucun identifiant écrit à la main hormis le réseau auquel on rattache la VIP. C’est la forme qu’il faut avant d’envelopper un load balancer dans une composition et de le confier aux équipes applicatives, le genre de frontière que nous dessinons dans nos missions de platform engineering.

network.ip est facultatif. Dans le CIDR du sous-réseau, il fixe l’adresse de la VIP. En dehors, il doit désigner une IP flottante existante à associer.

Ce n’est pas un remplacement de ProjectLoadbalancer. L’ancien kind du groupe lb encapsule une autre ressource amont, garde son propre schéma et n’est pas modifié. Rien ne bouge tant que vous ne le décidez pas. Comme Instance et ProjectInstance dans la 2.19.0, provider-ovh expose désormais les deux API OVHcloud sous forme de CRD distinctes, et il en va de même pour InstanceSnapshot à côté de l’ancien ProjectInstanceSnapshot.

Les autres nouveaux kinds

InstanceSnapshot crée un snapshot d’une Instance, et son instanceId se résout par référence ou par sélecteur. Depuis la version amont 2.23.0, il remonte l’osType du snapshot (LINUX, WINDOWS ou BAREMETAL_LINUX), hérité de l’image à partir de laquelle l’instance a été créée.

ObjectBucket, dans le groupe storage, gère directement un bucket Object Storage. La version amont 2.23.0 y corrige aussi la suppression des tags : retirer un tag de la spec le supprime désormais sur le bucket.

CephPool et CephUser, dans clouddiskarray, gèrent les pools et les utilisateurs d’un Cloud Disk Array. Ils rejoignent le kind CephACL existant.

DomainDKIM et DomainRedirection, dans email, gèrent la signature DKIM et les redirections d’un domaine email OVHcloud. Quand la zone DNS est hébergée ailleurs, DomainDKIM expose les CNAME des sélecteurs dans status.atProvider pour que vous les publiiez, et le DKIM reste en toConfigure tant que ce n’est pas fait.

IAMLogSubscription, APILogSubscription et AuditLogSubscription envoient les logs IAM, les logs d’appels API et les logs d’audit du compte vers un stream Logs Data Platform. Face à un auditeur qui demande où partent les traces d’activité du compte, un abonnement versionné dans Git et réconcilié est une meilleure réponse qu’un réglage cliqué une fois.

ServerVirtualMac attribue une MAC virtuelle à une IP additionnelle d’un serveur dédié, ce qu’il faut pour rattacher une VM en bridge sur cette IP. PrivatedatabaseWebhostingNetwork détermine si le réseau web hosting OVHcloud peut se connecter à une base de données SQL privée.

Les correctifs arrivés avec la montée amont

Passer quatre versions amont, c’est aussi récupérer leurs correctifs et les champs facultatifs qu’elles ont ajoutés. Deux sortent du lot.

Les mises à jour d’Instance ne détachent plus les réseaux

La version amont 2.21.0 corrige un bug sérieux dans les mises à jour de ovh_cloud_instance (#1451). L’API OVHcloud traite une clé absente d’une requête de mise à jour comme vide. Le provider envoyait des payloads partiels : une mise à jour pouvait détacher réseaux, volumes et partages, et réinitialiser securityGroupIds sur un port qui refuse tout.

Instance existe dans provider-ovh depuis la 2.19.0. Si vous l’utilisez en 2.19.x et que vous mettez à jour des instances, cela suffit à justifier la mise à jour. La 2.23.0 envoie tous les champs modifiables à chaque mise à jour.

User survit à un redémarrage

Le second correctif est le nôtre. Après le retrait de la CLI Terraform en 2.19.1, l’external-name service_name/user_id du kind User du groupe cloud ne se résolvait plus : les utilisateurs importés ne devenaient jamais prêts, et les utilisateurs créés cassaient après un redémarrage du provider. La 2.23.0 utilise l’identifiant brut de l’utilisateur comme external-name et normalise l’ancien format : les objets existants continuent de fonctionner sans rien changer de votre côté.

Les nouveaux champs à connaître

• BlockVolume : encryption.kms, pour chiffrer un volume avec une clé gérée par le client.
• FileShare : encryption au repos, et createFrom.snapshotId pour créer un partage à partir d’un snapshot. shareType et size ne sont plus obligatoires, puisqu’un partage créé depuis un snapshot les reprend de la source.
• Instance : userData, pour passer un cloud-init à la création.
• Cluster (kube) : disablePublicNetworking.
• Oauth2Client : discardClientSecret, pour ne pas garder le secret client dans l’état quand un compte de service ne s’en sert jamais.
• FirewallRule : destinationPortRange et sourcePortRange.
• ServerReinstallTask : customizations.appToInstall et storage.erase.

Le comportement de kinds existants s’améliore aussi. ProjectDatabase change networkId et subnetId sur place au lieu de recréer le cluster, et n’affiche plus de diff permanent sur advancedConfiguration. Les réglages des topics Kafka se mettent à jour sur place, sauf la baisse de partitions qui remplace toujours le topic.

Ruptures : aucune pour les manifestes

Nous avons comparé champ par champ le schéma du provider généré avec celui de la 2.19.0. Résultat : aucune ressource retirée, aucun champ retiré, aucun changement de type hormis de nouveaux attributs imbriqués, aucun champ devenu obligatoire et aucune montée de version de schéma d’état. Au niveau des CRD, les seules règles de validation retirées sont celles qui exigeaient shareType et size sur FileShare : le schéma s’est assoupli, pas durci.

API Go uniquement. Pour distinguer les nouveaux kinds, upjet a renommé deux types générés dans le groupe cloud :

LoadbalancerParameters appartient désormais au nouveau kind Loadbalancer. Les noms de champs JSON ne changent pas : manifestes et objets stockés ne sont pas affectés. Cela ne vous concerne que si vous importez directement apis/{cluster,namespaced}/..., dans une composition function, un opérateur ou un harnais de test. Dans ce cas, le compilateur vous montrera les deux endroits.

Toolchain : une montée amont, deux montées d’outillage

Un point pour qui maintient son propre provider upjet. La version amont 2.23.0 exige Go 1.27.3 : provider-ovh passe donc de Go 1.25.13 à 1.27.3. golangci-lint 2.5.0, compilé avec Go 1.25, refuse d’analyser un module Go 1.27 : il passe donc lui aussi en 2.15.0. Le linter goconst, plus récent, a alors signalé sept chaînes répétées dans le code existant, surtout des noms de ressources ovh_*, que nous excluons désormais dans .golangci.yml.

La leçon : avant de planifier une montée amont, regardez d’abord la directive go du go.mod amont. Une version mineure amont peut imposer une montée de toolchain, qui peut elle-même en imposer une autre.

Rien de tout cela ne change l’image que vous exécutez. C’est toujours le binaire Go unique sur Alpine introduit par la 2.19.1.

Mettre à jour

cat <<EOF | kubectl apply -f -
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-ovh
spec:
  package: xpkg.upbound.io/edixos/provider-ovh:v2.23.0
EOF

Aucune migration à préparer. Les nouvelles CRD s’installent à côté des existantes, et les objets managés existants continuent de se réconcilier. Si vous partez de la 2.19.0 ou d’une version antérieure, lisez d’abord la 2.19.1 : sa section migration reste valable, et l’un de ses changements rejette des objets CloudProject existants du groupe vrack.

Changelog complet : v2.19.1…v2.23.0 · notes de version

Remerciements

@Alegrowin a signé le correctif d’external-name de User dans la #68, testé sur ses propres clusters de production. C’est sa deuxième contribution après la #52, et elle referme une régression qui n’apparaît qu’après un redémarrage. Merci.

Merci aussi à l’équipe OVHcloud et aux contributeurs des quatre versions amont sur lesquelles celle-ci repose.

Si vous utilisez provider-ovh, les issues et pull requests sont le moyen le plus direct d’orienter la suite.

Pour aller plus loin

Si vous découvrez le provider, le guide pas à pas provider-ovh couvre l’installation, les credentials et un premier cluster managé. Vous partez d’une version plus ancienne ? Lisez la 2.19.1, puis la 2.18.0 et la 2.17.0, qui retirent des champs.

Nous maintenons provider-ovh et construisons des control planes OVHcloud dessus : conseil Crossplane · platform engineering · nous écrire.