Skip to content

Commit 9934014

Browse files
themoriartithemoriarti
committed
fix(capi): ship the core provider manifests the repository actually holds
#2946 added a startupProbe to capi-controller-manager so it survives the certificate provisioning delay. It edited capi-providers-core/files/core-components.yaml, which is the copy a reviewer reads. The chart mounts files/components.gz, and that blob was never regenerated, so the probe never reached a cluster. The blob is regenerated from the YAML it is supposed to carry: gzip -9 -n -c files/core-components.yaml > files/components.gz The decompressed blob now matches the YAML byte for byte, and the only change it carries is the six lines of #2946. This reaches new installs only. capi-operator re-applies a provider when the hash of its spec and its config Secret changes; the ConfigMap holding the components is in neither, so a cluster that already runs capi-providers-core keeps its manager without the probe until the provider's version moves. Whether existing clusters should get the probe, and how, is left open here on purpose: moving spec.version and the ConfigMap name together would force the re-apply, but that is a version decision for the package, not a side effect of regenerating a blob. .helmignore is corrected in the same change: `files/.*-components.yaml` is a glob, so it matched only names beginning with a dot, and `helm package` shipped the readable YAML alongside the blob that duplicates it. hack/capi-core-components_test.bats holds the two files to the same bytes from now on, so the next edit of one without the other fails in CI. Signed-off-by: Marian Koreniuk <[email protected]> Assisted-by: LLM
1 parent 6748014 commit 9934014

3 files changed

Lines changed: 33 additions & 1 deletion

File tree

‎hack/capi-core-components_test.bats‎

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
#!/usr/bin/env bats
2+
# capi-providers-core ships the Cluster API core manifests twice: as
3+
# files/core-components.yaml, which a reviewer reads, and as files/components.gz,
4+
# which the chart mounts into the cluster. Both are edited by hand; this package
5+
# has no `make components`. An edit to the YAML alone reviews cleanly and changes
6+
# nothing in a cluster, which is how the startupProbe from #2946 stayed out of
7+
# the shipped manager. This holds the two files to the same bytes.
8+
#
9+
# The comparison is on the decompressed bytes, so the gzip header plays no part
10+
# in it. `gzip -n` is still the flag to regenerate with: without it the header
11+
# carries a timestamp and every regeneration rewrites the committed blob even
12+
# when the input has not changed.
13+
14+
REPO_ROOT="$(cd "$(dirname "${BATS_TEST_FILENAME:-$0}")/.." && pwd)"
15+
FILES="$REPO_ROOT/packages/system/capi-providers-core/files"
16+
17+
@test "core provider components.gz matches core-components.yaml" {
18+
[ -f "$FILES/core-components.yaml" ] || { echo "missing core-components.yaml" >&2; return 1; }
19+
[ -f "$FILES/components.gz" ] || { echo "missing components.gz" >&2; return 1; }
20+
21+
local work; work="$(mktemp -d)"
22+
gzip -dc "$FILES/components.gz" > "$work/decompressed.yaml"
23+
if ! cmp -s "$work/decompressed.yaml" "$FILES/core-components.yaml"; then
24+
echo "components.gz does not match core-components.yaml" >&2
25+
echo "the chart mounts the blob, so the cluster would run what the YAML does not say" >&2
26+
echo "regenerate: gzip -9 -n -c files/core-components.yaml > files/components.gz" >&2
27+
diff "$work/decompressed.yaml" "$FILES/core-components.yaml" | head -20 >&2 || true
28+
rm -rf "$work"
29+
return 1
30+
fi
31+
rm -rf "$work"
32+
}

‎packages/system/capi-providers-core/.helmignore‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
files/.*-components.yaml
1+
files/*-components.yaml

‎packages/system/capi-providers-core/files/components.gz‎

-1.52 KB
Binary file not shown.

0 commit comments

Comments
 (0)