From b8a2858c0d29d680ff67764e41f2adb87cbca08b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20ROBERT?= Date: Mon, 14 Sep 2026 18:36:14 +0200 Subject: [PATCH] chore(exoscale): the provider constraint becomes an exact pin, and the safety floor stops depending on a registry's clock MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `examples/stacks/exoscale` asked for `>= 0.71.0`. The floor was right; writing it as a lower bound was the accident. WHAT A LOWER BOUND ACTUALLY RESOLVED TO `registry.terraform.io` and `registry.opentofu.org` do not index together, and this repository drives both engines over the same stack. Measured 2026-09-14: terraform 85 stable versions listed, `>= 0.71.0` resolved to 0.72.0 opentofu 84 stable versions listed, `>= 0.71.0` resolved to 0.71.0 **Two engines driving one stack with two different providers, both reporting that it passed.** docs/clients.md already says a constraint's resolved version "is not knowable here"; this is a step past that — it was not the SAME on the two legs. WHY IT MATTERS MORE HERE THAN ELSEWHERE `terraformProviderFloor` is `v0.71.0` because below it the provider honours EXOSCALE_API_ENDPOINT for only half its calls and the rest reach a paying account — 57 requests, measured in #525. While the window was open the opentofu leg sat EXACTLY on that floor. Not below it, and `guardSplitClients` would refuse a client that were. But the margin was zero, held there by an indexing schedule rather than by anything in this repository. That guard is the right last line; it should not be the first. The window closed on its own about forty minutes later, which is recorded in the report was wrong. The mechanism did not close: it reopens at every publication. It reopened for the Scaleway provider in the same hour. WHAT 0.72.0 CARRIES Read rather than assumed, from the commits between the two tags: SKS nodepool kubelet max-pods, a ClickHouse dbaas resource, a new zone es-mad-1, and re-enabled EIP tests. Nothing this emulator serves, which is why this is a pin move and not a compatibility change. PROVEN - `conformance:stacks`: green — the three stacks applied, re-planned with no resource change, destroyed. - And the part a green gate does NOT prove, measured separately because its log is filtered and does not say who answered: `init -upgrade` in a copy of the stack installs **0.72.0 under terraform and 0.72.0 under tofu**. A pass with a cached provider would have proved the wrong thing. - `mise run check` and `docs:check` green. docs/clients.md now reads "exact: the version that answered" for this row instead of "not knowable here". NOT IN THIS CHANGE The Outscale stacks keep `~> 1.7`. They agree across both registries today by luck rather than by construction, and the same window will open at their next publication — that is the general half of #778, and it is a decision rather than an oversight. Assisted-by: Claude Code (claude-opus-5) --- docs/clients.md | 2 +- examples/stacks/exoscale/main.tf | 18 ++++++++++++++++-- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/docs/clients.md b/docs/clients.md index 44b0c704..8bc7c929 100644 --- a/docs/clients.md +++ b/docs/clients.md @@ -77,7 +77,7 @@ Each row is one `required_providers` entry, read where it is written. | `tools/conformance/outscale/terraform` | `outscale/outscale` | `~> 1.7` | constraint: resolved fresh on each run, so the version that answered is not knowable here | yes | | `tools/conformance/outscale/terraform-doorway` | `outscale/outscale` | `~> 1.7` | constraint: resolved fresh on each run, so the version that answered is not knowable here | yes | | `tools/conformance/scaleway/terraform` | `scaleway/scaleway` | `2.83.0` | exact: the version that answered | yes | -| `examples/stacks/exoscale` | `exoscale/exoscale` | `>= 0.71.0` | constraint: resolved fresh on each run, so the version that answered is not knowable here | yes | +| `examples/stacks/exoscale` | `exoscale/exoscale` | `0.72.0` | exact: the version that answered | yes | | `examples/stacks/outscale` | `outscale/outscale` | `~> 1.7` | constraint: resolved fresh on each run, so the version that answered is not knowable here | yes | | `examples/stacks/outscale/modules/net` | `outscale/outscale` | `~> 1.7` | constraint: resolved fresh on each run, so the version that answered is not knowable here | yes | | `examples/stacks/scaleway` | `scaleway/scaleway` | `2.83.0` | exact: the version that answered | yes | diff --git a/examples/stacks/exoscale/main.tf b/examples/stacks/exoscale/main.tf index 04dd33fc..36c8fb37 100644 --- a/examples/stacks/exoscale/main.tf +++ b/examples/stacks/exoscale/main.tf @@ -33,9 +33,23 @@ terraform { required_providers { exoscale = { source = "exoscale/exoscale" - # Not decoration: below this the provider splits its calls between this + # Not decoration: below 0.71.0 the provider splits its calls between this # emulator and a paying account (#644, upstream #573). - version = ">= 0.71.0" + # + # Exact rather than `>= 0.71.0`, since 2026-09-14. The floor was right and + # the FLOATING part was an accident of writing it as a lower bound: the two + # registries do not index together, so on that day `>= 0.71.0` resolved to + # 0.72.0 under terraform and to 0.71.0 under opentofu — the two engines + # driving this one stack with two different providers, both reporting that + # it passed. Worse, the opentofu side then sat EXACTLY on the floor, with + # the 57-request excursion of #525 one publication away, and the margin + # held by a registry's indexing schedule rather than by anything here. + # Measured, and recorded in #778. + # + # 0.72.0 is above the floor and is what both registries serve. Moving it + # is now an act somebody performs and measures, which is the whole reason + # the Scaleway fixture is pinned exactly too (#257). + version = "0.72.0" } } }