Repository navigation
isp-hosted preset cannot converge: paas/naas enabled while their dependency closure sits behind the disabled system bundle #3376
Description
Symptom
A fresh isp-hosted platform install (v1.6.0-rc.2, Kamaji tenant cluster) never converges: the cozystack-platform HelmRelease loops on timeout waiting for: [Package/cozystack.harbor-application status: 'InProgress', Package/cozystack.qdrant-application ...] with every *-application Package stuck DependenciesNotReady, and the *-rd HelmReleases fail no matches for kind "ApplicationDefinition" in version "cozystack.io/v1alpha1".
Mechanism
values-isp-hosted.yaml ships bundles.system.enabled: false while paas: true and naas: true. But templates/bundles/system.yaml is gated entirely on bundles.system.enabled — and inside that gate live everything the app catalog depends on:
cozystack.cozystack-engine— the sole source of theapplication-definition-crdcomponent (sources/cozystack-engine.yaml), i.e. theApplicationDefinitionCRD the*-rdreleases need. fix(platform): make *-rd sources depend on cozystack-engine #3041 made the*-rdsources dependOn cozystack-engine, which fixed the race on full variants but on isp-hosted converts the CRD error into a forever-wait, since the engine Package is never rendered.cozystack.networking(even the isp-hosted noop variant lives inside the system gate),cozystack.postgres-operator,cozystack.objectstorage-controller— all listed in e.g.sources/harbor-application.yamlvariantdependsOn.redis-operatorIS emitted by the paas bundle but itself dependsOncozystack.networking→ also stuck.
Net effect: the preset enables an app catalog whose dependency closure it simultaneously disables. Nothing on main after the rc.2 tag touches this gating.
Reproduction
Apply Package cozystack.cozystack-platform variant isp-hosted with defaults on a Kamaji tenant cluster (base installed from the v1.6.0-rc.2 cozystack-operator-hosted.yaml assets). Observed 2026-07-20.
Workaround
Set bundles.paas.enabled: false and bundles.naas.enabled: false in the platform Package values (and hand-copy the applicationdefinitions.cozystack.io CRD if the *-rd releases are wanted). Note existing *-application Package CRs are helm.sh/resource-policy: keep, so after disabling the bundles they must be deleted manually.
Suggested fix
Either move the app-catalog dependency closure (engine incl. application-definition-crd, noop networking, postgres-operator, objectstorage-controller) out of the bundles.system.enabled gate for the hosted variant, or ship the preset with paas/naas disabled so the default converges.
Activity
myasnikovdaniil commentedon Jul 21, 2026
Release assessment: not a blocker for cutting 1.6
This is not a 1.6 regression. The preset has been unable to converge since it was introduced in
2d022e38e(January 2026), the refactor that replacedbundles/paas-hosted.yaml. I verified the identical wedge onorigin/release-1.5: renderingvalues-isp-hosted.yamlthere emits 24 Packages, all of them blocked, by 5 unsatisfiable dependencies. So 1.5 shipped with this and cutting 1.6 makes nothing worse for anyone.The stronger reason not to block on it: #3391 does not fully resolve this either. That PR restores the dependency closure — hosted goes from 24 Packages all blocked to 53 with every
dependsOnsatisfied — but reviewing it surfaced further hosted-unaware defaults that the disabled bundle had been masking. #3387 is the remaining blocker for actual convergence:apps/tenantrenders 14cilium.io/v2policies with no.Capabilitiesguard, sotenant-rootfails on a cluster without Cilium, which the hosted variant is by definition. Fixing that well is a security decision rather than a mechanical capability guard, because those policies implement tenant network isolation. That is not release-window work, so blocking 1.6 on "hosted must converge" means blocking on an open-ended task, not on merging a ready PR.Two things worth doing anyway
Merge #3391 into 1.6 regardless. The blast radius on the variants people actually use is nil —
isp-fullandisp-full-genericrender byte-identically before and after the change, verified. The practical gain is diagnosability: instead of sitting inDependenciesNotReadyindefinitely with nothing in the output naming the cause, a hosted install now reaches a specific, greppable failure. Turning an unbounded silent hang into a named error is most of the value here even without full convergence.Disclose it, because this is a published artifact rather than a latent preset.
cozystack-operator-hosted.yamlis built by themanifeststarget and uploaded to every release byhack/upload-assets.sh, which is how this was hit in the first place. Either note the limitation in the 1.6 release notes pointing at #3387, or stop publishing that asset until #3387 lands. The second is a one-line change and is arguably more honest than shipping an installer that cannot work.Backport
#3391 cherry-picks onto
release-1.5with zero conflicts and passes there (69/69 platform unit tests, all variants dependency-closed). No reason to do that in parallel with the 1.6 cut — better to let the fix settle on main first and backport the reviewed version.fix(platform): restore the isp-hosted dependency closure
fix(platform): restore the isp-hosted dependency closure (cozystack#3391
ci(e2e): add a daily isp-hosted install lane on kind (#4712)