Conversation
✅ Deploy Preview for replicated-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for replicated-docs-upgrade ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Both Embedded Cluster overview pages stated that vendors cannot supply their own host preflight spec. That is wrong on v2 and v3: a `kind: HostPreflight` resource in the release is merged with the built-in checks and runs on install and node join. Correct the limitation to what is actually true (the defaults cannot be modified or removed) and add a section showing how to add custom checks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
918dac2 to
82d8c7e
Compare
Embedded Cluster v2 honors `strict: true` on host preflight analyzers, matching v3, so document it the same way on both pages. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
90e7bff to
cd65053
Compare
AmberAlston
left a comment
There was a problem hiding this comment.
Approving. I verified the correction against the code in both repos and it's right. A vendor HostPreflight in the release is merged with the defaults, the defaults can't be modified or removed, and the operations you list per version match what the code does, with v2 running them on install and node join and v3 also on upgrade.
Please don't merge yet. The strict: true sections describe behavior that isn't in a released EC v2.
Two things have to land first:
- replicatedhq/embedded-cluster#3834 bumps
TROUBLESHOOT_VERSIONfrom v0.133.0 to v0.134.1. That's the release where troubleshoot started propagatingstrictfrom host analyzer specs into results (replicatedhq/troubleshoot#2132). - replicatedhq/embedded-cluster#3967 is the gate that honors it.
Neither works alone. I ran the example spec from this PR against both binaries to confirm. On v0.133.0 the JSON output has no strict field at all, so HasStrictFailures() is always false and --ignore-host-preflights still bypasses. On v0.134.1 it comes through.
Once the EC v2 release with both is out, can you add the minimum version to the v2 page? The 2.0.0 versioned docs cover every 2.x, so without it someone on 2.19 reads a guarantee that doesn't hold on their binary.
On the v3 page, strict is accurate for 3.13.0-beta.1, which was built after troubleshoot v0.134.1 shipped. Worth knowing that 3.12.0-beta.1 and earlier were built in August and carry an older preflight binary, so strict silently does nothing there. v3 resolves the version from replicated.app/ping at bundle build time rather than pinning it.
Two optional additions, take or leave:
- Say to put all custom host checks in a single HostPreflight resource. If a release has two, v3 uses the first match and v2 lets the last file win, with no error either way.
- On the v3 page, a spec that fails to parse doesn't stop the install. v3 runs the defaults, warns that the vendor host preflights were skipped, and continues.
Separately, I'll open a docs PR for something this surfaced that isn't yours to fix here. Several pages say preflight specs must use v1beta3 on v3, when the rule is really about the Preflight kind. HostPreflight has no v1beta3 and stays v1beta2, which your page gets right, but the surrounding docs imply otherwise.
A release with more than one HostPreflight resource silently uses only the first on v3, and a spec that fails to parse warns and continues rather than stopping the install. Both surfaced in review. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Strict host preflight checks need troubleshoot v0.134.1, which ships in Embedded Cluster 3.13.0 and 2.19.12. Both versioned pages cover every release in their major, so name the floor rather than imply it always worked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both Embedded Cluster overview pages stated that vendors cannot supply their own host preflight spec. That is wrong on v2 and v3: a
kind: HostPreflightresource in the release runs in addition to the default checks.Correct the limitation to what is actually true (the defaults cannot be modified or removed) and add a section showing how to add custom checks.
When the checks run differs by version, and the pages now say so: v2 runs them on install and node join, v3 also runs them on upgrade. The v3 section additionally documents
strict: true, which makes a failed check non-bypassable from both the UI and--ignore-host-preflights.Preview
🤖 Generated with Claude Code