provider-ovh 2.17.0 : couverture complète du schéma OVHcloud pour Crossplane

À retenir

• provider-ovh 2.17.0 câble l’intégralité du schéma du provider Terraform OVHcloud : 165 ressources managées par scope d’API et 335 CRD, contre 138 et 281 auparavant.
• Quatre moteurs de bases de données ont disparu en amont. Migrez ou supprimez les objets des kinds retirés avant de mettre à jour — les CRD sont supprimées, pas dépréciées.
• Les 31 nouveaux kinds sont en bêta : générés, compilés et testés unitairement, mais pas encore éprouvés de bout en bout sur un compte réel.

provider-ovh est le provider Crossplane pour OVHcloud que nous développons et maintenons chez Edixos. La version 2.17.0, publiée le 25 juillet 2026, passe au provider Terraform OVHcloud 2.17.0 et expose pour la première fois toutes les ressources du schéma amont en ressources managées Crossplane.

C’est l’annonce principale. Ce qui demande votre attention avant la mise à jour, ce sont les suppressions.

Ce que contient réellement la 2.17.0

Chaque ressource existe dans les deux groupes d’API livrés par le provider : *.ovh.edixos.io au niveau cluster et *.ovh.m.edixos.io au niveau namespace. C’est ce doublement qui explique un nombre de CRD environ deux fois supérieur au nombre de ressources.

Ruptures : à lire avant de mettre à jour

L’amont 2.17.0 a retiré les moteurs dépréciés cassandra, m3db, m3aggregator et redis, ainsi que la ressource ovh_cloud_project_database_ip_restriction, dépréciée de longue date. Les CRD correspondantes sont supprimées.

Migrez ou supprimez tout objet des kinds retirés avant la mise à jour. Retirer une CRD alors que des objets managés y font encore référence vous laisse des ressources que Crossplane ne peut plus réconcilier, et des finalizers à nettoyer à la main.

ProjectDatabase valide désormais engine côté client. Les valeurs supportées sont clickhouse, grafana, kafka, kafkaConnect, kafkaMirrorMaker, mongodb, mysql, opensearch, postgresql et valkey — toute autre valeur est rejetée avant d’atteindre l’API OVHcloud, ce qui échoue plus vite qu’une erreur distante.

Basculer les restrictions IP dans la base parente

apiVersion: databases.ovh.edixos.io/v1alpha1
kind: ProjectDatabase
metadata:
  name: example-postgres
spec:
  forProvider:
    serviceName: <service-name>
    engine: postgresql
    version: "16"
    plan: business
    ipRestrictions:
      - ip: 10.0.0.0/24
        description: platform-team

Supprimez d’abord les objets ProjectDatabaseIPRestriction autonomes, puis appliquez la base parente avec les règles déclarées.

31 nouvelles ressources

Le passage en schéma complet couvre désormais l’essentiel de la surface OVHcloud :

Une décision de conception mérite d’être signalée : IdentityUserToken écrit son token dans le secret de connexion plutôt que dans le statut, parce que l’attribut amont est marqué sensible. Un secret dans status est lisible par tout ce qui a un droit de lecture sur la ressource ; un secret de connexion est un objet distinct, dont les droits se gèrent séparément.

Note de périmètre, en toute franchise

Ces 31 kinds sont générés, compilés, lintés et couverts par des tests unitaires, et leurs identifiants Terraform suivent la documentation d’import amont. Ils n’ont pas été éprouvés de bout en bout sur un compte OVHcloud réel. Traitez-les comme de la bêta, et ouvrez une issue en cas de problème — ces retours sont ce qui les fera sortir de bêta.

Améliorations de schéma héritées des versions 2.14.0 à 2.17.0

Quatre versions amont sont intégrées d’un coup, d’où plusieurs champs jamais annoncés ici individuellement :

• ovh_cloud_project_kube : ip_allocation_policy, customization_cilium
• ovh_cloud_project_volume : encryption, pour les volumes chiffrés par clé client
• ovh_cloud_project_storage : tags
• ovh_dbaas_logs_output_graylog_stream : encryption_keys_ids

Corrections de comportement sur la même période : mise à l’échelle des nœuds sans recréation pour ovh_cloud_project_database ; création de base idempotente sur les réponses 409 et 500 ; desired_nodes plafonné lors de la réduction d’un nodepool ; état UPDATING accepté comme état Kubernetes transitoire ; et weight: 0 traité comme une vraie valeur sur les routes de load-balancer plutôt que comme une absence de valeur.

Ce dernier point est typiquement le bug qui ne se voit qu’en production : une route pondérée à zéro est un drain volontaire, et la traiter comme absente y réinjecte du trafic sans prévenir.

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.17.0
EOF

L’ordre des opérations qui évite les ennuis :

1. Inventorier les objets des quatre kinds supprimés, dans tous les namespaces.
2. Basculer les restrictions IP sur la ProjectDatabase parente, et les utilisateurs Redis vers Valkey.
3. Supprimer les objets restants des kinds retirés.
4. Appliquer la mise à jour du provider ci-dessus.
5. Vérifier que le package est sain : kubectl get providers.pkg.crossplane.io provider-ovh.

Sauter l’étape 3 fait disparaître les CRD sous des objets vivants, et vous laisse nettoyer les finalizers à la main. C’est réparable, mais cela ressemble beaucoup à une après-midi d’incident.

Changelog complet : v2.13.2…v2.17.0

Pour aller plus loin

Vous découvrez le provider ? Commencez par le guide pas à pas provider-ovh — installation sur kind, branchement des credentials, déploiement d’un cluster managé. Lisez ensuite provider-ovh 2.18.0, qui retire les accessRules en ligne de FileShare d’une manière qui échoue en silence.

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