content/en/docs/v1.0/operations/configuration/components.md is published and still carries two defects that its successor pages are being corrected for. v1.0 was left out of that correction deliberately and for a good reason, since it needs different text rather than the same text, but the page stands as written in the meantime.
The serious one is the removal recipe at line 70, kubectl delete hr -n <namespace> <component>. At v1.0.0 the operator puts a controller ownerReference from the Package onto every HelmRelease it builds (internal/operator/package_reconciler.go:253, with Controller: true at :259) and reconciles on Owns(&helmv2.HelmRelease{}) at :932. Deleting the HelmRelease therefore makes Flux uninstall the release, which removes the CRDs the chart renders as ordinary templates and cascades every custom resource of those kinds cluster-wide. The operator then recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not, and nothing on screen says anything happened.
The second is lines 59 and 61, and the same two names at install/providers/hetzner.md:347,349: disabledPackages entries written bare as metallb and hetzner-robotlb. At v1.0.0 the platform chart passes fully-qualified names into the disable check, _helpers.tpl:64 feeding cozystack.metallb against a has $name $disabled guard, so a bare entry matches nothing and the example disables nothing. That is the same defect just corrected for v1.1, on both page types, including the provider guide where swapping MetalLB for RobotLB is a required step rather than an illustration.
What v1.0 needs is not the two-step Package recipe the later versions got. packages/core/platform/templates/_helpers.tpl carries no helm.sh/resource-policy at v1.0.8, so on this line the disabledPackages edit removes the component by itself and there is no second step at all. The correction here is a shorter page, not a copy of the newer one.
Worth settling alongside it: whether v1.0 is supported enough to correct, or whether the page should carry a banner sending readers to a supported release. Leaving a recipe that destroys data without a warning is the one option that should be off the table either way.
content/en/docs/v1.0/operations/configuration/components.mdis published and still carries two defects that its successor pages are being corrected for. v1.0 was left out of that correction deliberately and for a good reason, since it needs different text rather than the same text, but the page stands as written in the meantime.The serious one is the removal recipe at line 70,
kubectl delete hr -n <namespace> <component>. At v1.0.0 the operator puts a controller ownerReference from the Package onto every HelmRelease it builds (internal/operator/package_reconciler.go:253, withController: trueat:259) and reconciles onOwns(&helmv2.HelmRelease{})at:932. Deleting the HelmRelease therefore makes Flux uninstall the release, which removes the CRDs the chart renders as ordinary templates and cascades every custom resource of those kinds cluster-wide. The operator then recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not, and nothing on screen says anything happened.The second is lines 59 and 61, and the same two names at
install/providers/hetzner.md:347,349:disabledPackagesentries written bare asmetallbandhetzner-robotlb. At v1.0.0 the platform chart passes fully-qualified names into the disable check,_helpers.tpl:64feedingcozystack.metallbagainst ahas $name $disabledguard, so a bare entry matches nothing and the example disables nothing. That is the same defect just corrected for v1.1, on both page types, including the provider guide where swapping MetalLB for RobotLB is a required step rather than an illustration.What v1.0 needs is not the two-step Package recipe the later versions got.
packages/core/platform/templates/_helpers.tplcarries nohelm.sh/resource-policyat v1.0.8, so on this line thedisabledPackagesedit removes the component by itself and there is no second step at all. The correction here is a shorter page, not a copy of the newer one.Worth settling alongside it: whether v1.0 is supported enough to correct, or whether the page should carry a banner sending readers to a supported release. Leaving a recipe that destroys data without a warning is the one option that should be off the table either way.