provider-ovh 2.17.0: full OVHcloud schema coverage for Crossplane

Key takeaways

• provider-ovh 2.17.0 wires the complete OVHcloud Terraform provider schema: 165 managed resources per API scope and 335 CRDs, up from 138 and 281.
• Four database engines disappeared upstream. Migrate or delete objects of the removed kinds before you upgrade — the CRDs are gone, not deprecated.
• The 31 newly wired kinds are beta: generated, built and unit-tested, but not yet exercised end to end against a live account.

provider-ovh is the Crossplane provider for OVHcloud that we build and maintain at Edixos. Version 2.17.0, released 25 July 2026, upgrades to OVHcloud Terraform provider 2.17.0 and — for the first time — exposes every resource in the upstream schema as a Crossplane managed resource.

That is the headline. The part that needs your attention before you upgrade is the removals.

What 2.17.0 actually contains

Every resource is available in both API groups the provider ships: the cluster-scoped *.ovh.edixos.io and the namespaced *.ovh.m.edixos.io. That doubling is why the CRD count is roughly twice the resource count.

Breaking changes: read this before upgrading

Upstream 2.17.0 removed the deprecated cassandra, m3db, m3aggregator and redis database engines, along with the long-deprecated ovh_cloud_project_database_ip_restriction resource. The corresponding CRDs are gone.

Migrate or delete any objects of the removed kinds before upgrading. Removing a CRD while managed objects still reference it leaves you with resources Crossplane can no longer reconcile, and finalizers that need clearing by hand.

ProjectDatabase now validates engine client-side. The supported set is clickhouse, grafana, kafka, kafkaConnect, kafkaMirrorMaker, mongodb, mysql, opensearch, postgresql and valkey — anything else is rejected before it reaches the OVHcloud API, which is a faster failure than waiting for a remote error.

Moving IP restrictions inline

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

Delete the standalone ProjectDatabaseIPRestriction objects first, then apply the parent database with the rules inline.

31 new resources

The full-schema pass adds coverage across most of the OVHcloud surface:

One deliberate design decision worth calling out: IdentityUserToken writes its token to the connection secret rather than to status, because the upstream attribute is marked sensitive. A credential in status is readable by anything with get access on the resource; a connection secret is a separate object you can RBAC independently.

Honest scope note

These 31 kinds are generated, built, linted and unit-tested, and their Terraform identifiers follow the upstream import documentation. They have not been exercised end to end against a live OVHcloud account. Treat them as beta, and open an issue if you hit something — that feedback is what promotes them out of beta.

Schema improvements inherited from 2.14.0–2.17.0

Four upstream releases folded in at once, so several fields appear that were never announced here individually:

• ovh_cloud_project_kube: ip_allocation_policy, customization_cilium
• ovh_cloud_project_volume: encryption, for customer-managed-key encrypted volumes
• ovh_cloud_project_storage: tags
• ovh_dbaas_logs_output_graylog_stream: encryption_keys_ids

Behavioural fixes in the same span: in-place node scaling for ovh_cloud_project_database; idempotent database creation on 409 and 500 responses; desired_nodes capped when shrinking a nodepool; UPDATING accepted as a pending Kubernetes state; and weight: 0 treated as a real value on load-balancer routes rather than as unset.

That last one is the kind of bug that only shows up in production: a route weighted zero is a deliberate drain, and treating it as absent silently re-enables traffic.

Upgrading

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

Order of operations that avoids trouble:

1. Inventory objects of the four removed kinds across every namespace.
2. Move IP restrictions inline on the parent ProjectDatabase, and Redis users to Valkey.
3. Delete the leftover objects of removed kinds.
4. Apply the provider upgrade above.
5. Confirm the package became healthy: kubectl get providers.pkg.crossplane.io provider-ovh.

If you skip step 3, the CRDs vanish underneath live objects, and you clean up finalizers by hand afterwards. It is recoverable, but it is an outage-shaped afternoon.

Full changelog: v2.13.2…v2.17.0

Where to go next

New to the provider? Start with the step-by-step provider-ovh guide — install on kind, wire credentials, deploy a managed cluster. Then read provider-ovh 2.18.0, which removes inline accessRules from FileShare in a way that fails quietly.

We maintain provider-ovh, and we build OVHcloud control planes on it for a living: Crossplane consulting · platform engineering · talk to us.