À retenir

  • provider-ovh 2.18.0 ajoute FileShareACL et retire les accessRules en ligne de FileShare.
  • Le champ supprimé est élagué en silence, pas rejeté. Un manifeste FileShare inchangé continue de s’appliquer proprement pendant que ses règles d’accès cessent discrètement d’être gérées. C’est le point à vérifier avant de mettre à jour.
  • Les règles déjà provisionnées chez OVHcloud ne sont pas supprimées par la mise à jour : adoptez-les avec crossplane.io/external-name.

La version 2.18.0 de provider-ovh, notre provider Crossplane pour OVHcloud, est sortie le 1er août 2026. Elle suit le provider Terraform OVHcloud 2.18.0 et porte le provider à 166 ressources managées par scope d’API et 337 CRD.

C’est une petite version avec une arête vive, alors commençons par l’arête.

La rupture qui ne s’annonce pas

L’amont a retiré l’attribut access_rules en ligne de ovh_cloud_storage_file_share et l’a remplacé par une ressource ACL autonome. FileShare perd donc quatre chemins, dans les deux groupes d’API :

  • spec.forProvider.accessRules
  • spec.initProvider.accessRules
  • status.atProvider.accessRules
  • status.atProvider.currentState.accessRules

Voici pourquoi cette suppression mérite plus d’attention qu’une autre. Une fois les CRD mises à jour, accessRules n’est pas rejeté. L’API server Kubernetes élague les champs inconnus : un manifeste FileShare auquel vous n’avez pas touché s’appliquera encore, se déclarera prêt, et paraîtra parfaitement sain dans kubectl — pendant que les règles d’accès qu’il déclarait ne sont plus gérées par quoi que ce soit.

Une rupture qui échoue est une contrariété. Une rupture qui réussit est un piège. Auditez vos objets FileShare avant la mise à jour, pas après.

kubectl get fileshares.storage.ovh.edixos.io -A \
  -o jsonpath='{range .items[?(@.spec.forProvider.accessRules)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

Migrer vers FileShareACL

Déclarez une FileShareACL par règle auparavant en ligne :

apiVersion: storage.ovh.edixos.io/v1alpha1
kind: FileShareACL
metadata:
  name: example-acl
spec:
  forProvider:
    serviceName: <service-name>
    shareIdRef:
      name: example-share
    accessTo: 10.0.0.0/24
    accessLevel: READ_WRITE

accessTo prend une IP ou un CIDR unique. accessLevel vaut READ_WRITE ou READ_ONLY. shareId se résout par référence ou par sélecteur vers un FileShare, ce qui permet à l’ACL de suivre le partage plutôt que de figer un identifiant.

Une propriété à intégrer dès la conception : chaque champ configurable force une recréation. Il n’existe pas de mise à jour en place d’une ACL — modifier accessTo ou accessLevel la supprime et la recrée. Pour une règle qui gouverne du trafic en production, cela ouvre une courte fenêtre sans ACL : planifiez les changements en conséquence plutôt que de le découvrir pendant un incident.

Adopter les règles existantes

La mise à jour ne supprime pas les règles d’accès déjà provisionnées chez OVHcloud. Elles continuent de fonctionner ; elles ne sont simplement plus gérées. Pour en reprendre une sous Crossplane sans créer de doublon, fixez le nom externe :

metadata:
  name: example-acl
  annotations:
    crossplane.io/external-name: <serviceName>/<shareId>/<aclId>

Puisque chaque champ force une recréation, l’adoption est nettement préférable au « je recrée et j’espère » : elle évite un cycle suppression/création sur une règle qui laisse passer du trafic de production.

Également dans la 2.18.0

BlockVolume gagne un availabilityZone optionnel, ainsi que status.atProvider.currentState.location.availabilityZone. Si vous répartissez vos charges entre zones OVHcloud, vous pouvez désormais épingler un volume au lieu de subir son placement.

BlockVolume ne recrée plus le volume quand encryption reste inchangé. L’amont conserve désormais la valeur venue de l’état. Auparavant, un champ de chiffrement pourtant inchangé pouvait déclencher une recréation — sur un volume bloc, cela signifie déplacer des données. Si vous aviez un BlockVolume qui semblait vouloir se recréer sans raison, c’était probablement cela.

L’image du provider télécharge maintenant le binaire natif du provider Terraform depuis les assets de release GitHub amont plutôt que depuis releases.hashicorp.com. La raison est concrète : ce miroir ne porte qu’une partie des versions du provider OVHcloud, et ne propose pas du tout la 2.18.0. Passer par les assets amont garantit que le provider ne dépend plus d’un miroir en retard ou incomplet.

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

La séquence qui évite le piège :

  1. Auditer les objets FileShare à la recherche d’accessRules et relever chaque règle — IP ou CIDR, et niveau d’accès.
  2. Récupérer les aclId correspondants depuis l’API OVHcloud, en vue de l’adoption.
  3. Mettre à jour le provider.
  4. Appliquer une FileShareACL par règle relevée, avec crossplane.io/external-name positionné pour adopter la règle existante.
  5. Vérifier que chaque ACL atteint SYNCED et READY, et qu’aucune règle en doublon n’est apparue sur le partage.

Vous venez d’une 2.13.x plutôt que de la 2.17.0 ? Lisez d’abord provider-ovh 2.17.0 : elle retire quatre moteurs de bases de données et leurs CRD, une migration plus lourde que celle-ci.

Changelog complet : v2.17.0…v2.18.0

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é.

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

Réponses directes

Questions fréquentes

Qu'est-ce qui change dans provider-ovh 2.18.0 ?

La version passe au provider Terraform OVHcloud 2.18.0 et atteint 166 ressources managées par scope d'API et 337 CRD. Elle ajoute la ressource FileShareACL, dote BlockVolume d'un availabilityZone, et retire l'attribut accessRules en ligne de FileShare.

Pourquoi mes accessRules FileShare ne fonctionnent-elles plus après la mise à jour ?

Parce que le champ a été supprimé en amont et qu'il est élagué en silence par l'API server plutôt que rejeté. Le manifeste s'applique toujours proprement et l'objet se réconcilie toujours, mais les règles d'accès ne sont plus gérées. Déclarez une FileShareACL par règle.

Comment migrer les accessRules de FileShare vers FileShareACL ?

Créez une FileShareACL par règle auparavant en ligne, avec accessTo pour l'IP ou le CIDR et accessLevel à READ_WRITE ou READ_ONLY. Les règles déjà provisionnées chez OVHcloud ne sont pas supprimées par la mise à jour : adoptez-les via l'annotation crossplane.io/external-name.

Quel est le format d'external-name pour FileShareACL ?

L'annotation crossplane.io/external-name doit valoir serviceName/shareId/aclId. Cela permet à Crossplane d'adopter une règle d'accès existante chez OVHcloud au lieu d'en créer un doublon, ce qui compte d'autant plus que chaque champ configurable de FileShareACL force une recréation.

Pourquoi provider-ovh récupère-t-il désormais le binaire Terraform depuis GitHub ?

Parce que releases.hashicorp.com ne miroite qu'une partie des versions du provider OVHcloud et ne propose pas du tout la 2.18.0. L'image du provider télécharge maintenant le binaire natif depuis les assets de release GitHub amont, source faisant autorité pour toutes les versions.