Repository navigation
e2e: every observation of the kubernetes-oidc-customconfig teardown is censored, so its cleanup budget is unverified #3801
Description
No run shows how long this suite's teardown takes. Every observation of it ends at the cleanup budget instead.
What the census shows
19 Pull Request workflow runs, window 31315492733 to 31373204907, give 38 tenant-cluster teardowns, each measured between that E2E (in-tree) job's own CLEANUP | BEGIN and CLEANUP | END/ERROR lines. 35 finished: median 233s, maximum 263s, against the 300s cleanup budget in hack/e2e-chainsaw/.chainsaw.yaml. Three did not, and those three are censored at the ceiling rather than measured.
kubernetes-oidc-customconfig is in the censored group in both runs where its teardown is observable at all. One is 31373204907. The other is 31582632048 at head 5e470d507: all four steps passed in 4.4556s, then CLEANUP | BEGIN at 11:18:37.6723300 ran to CLEANUP | ERROR at 11:23:37.6720118, which is 299.9997s. The budget exhausted to within a third of a millisecond. Two observations agree the suite spends all of it, and neither shows what it would have needed.
A censored observation carries a lower bound and nothing else. So "this teardown fits in 5m" has never been tested for this suite in either direction.
The sibling suite, for contrast
kubernetes-oidc-system is where a real split exists. On run 31373204907 the bootstrap Job's completion event places the install's return inside a one-minute window, cutting that suite's 253.71s of cleanup into an install remainder of (57, 117]s and a teardown of [137, 197)s; the derivation is in the #3737 thread. The teardown is the larger half there, and it fits.
The same derivation on kubernetes-oidc-customconfig gives a remainder of (99.3, 159.3]s and a teardown of at least 140.7s, with no upper bound, because it had not finished when the cut fell.
Why now
The change for #3737 takes the install remainder out of cleanup for both suites, so afterwards cleanup carries the teardown alone. For kubernetes-oidc-system that remainder is measured and fits. For kubernetes-oidc-customconfig it is the quantity named here, and no measurement of it exists.
Scope
The teardown cost predates that change and is not caused by it. Adjacent but separate: #3739 is the worker VM both fixtures provision and then delete, #3754 is the catch collectors on the failure path. Neither states this bound. Nothing is proposed here beyond getting a real number, which the run list can give.
Activity
lexfrei commentedon Sep 7, 2026
One of the two terms this budget pays for is going away. A release still mid-install cannot be uninstalled, so on these suites the remainder of the install was billed to cleanup on top of the teardown: 57-117s out of the 253.71s total. #3802 moves that wait into an explicit assert inside
try, so cleanup is left paying for the teardown alone.So the numbers above mix two things, and after that merge they stop mixing. The 137-197s teardown band is derived by subtracting the install remainder from the total, and both observations of it are right-censored at 300s, which makes it a lower bound rather than a duration.
When the budget does get set, it should be per-Test
spec.timeoutson the two OIDC Tests, not the global value in.chainsaw.yaml. The global one serves every suite in the directory, and only this pair has evidence of a slow teardown. Worth setting from the tail of a distribution, not from one run: the lever is free on a passing run and not free on a failing one, since it widens what a stuck uninstall can spend before the suite reds.myasnikovdaniil commentedon Sep 22, 2026
Closing, same reason as #3737. #4020 removed
kubernetes-oidc-customconfigas a standalone suite, its checks run on the latest-version tenant cluster now, so there is no separate teardown left to put a number on. If cleanup budget of the merged suite turns out censored the same way, that is a new issue against that suite.