Repository navigation
isp-hosted preset cannot converge: paas/naas enabled while their dependency closure sits behind the disabled system bundle #3376
Description
Activity
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.- added a commit that references this issue
on Oct 5, 2026
Symptom
A fresh
isp-hostedplatform install (v1.6.0-rc.2, Kamaji tenant cluster) never converges: thecozystack-platformHelmRelease loops ontimeout waiting for: [Package/cozystack.harbor-application status: 'InProgress', Package/cozystack.qdrant-application ...]with every*-applicationPackage stuckDependenciesNotReady, and the*-rdHelmReleases failno matches for kind "ApplicationDefinition" in version "cozystack.io/v1alpha1".Mechanism
values-isp-hosted.yamlshipsbundles.system.enabled: falsewhilepaas: trueandnaas: true. Buttemplates/bundles/system.yamlis gated entirely onbundles.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-platformvariantisp-hostedwith defaults on a Kamaji tenant cluster (base installed from the v1.6.0-rc.2cozystack-operator-hosted.yamlassets). Observed 2026-07-20.Workaround
Set
bundles.paas.enabled: falseandbundles.naas.enabled: falsein the platform Package values (and hand-copy theapplicationdefinitions.cozystack.ioCRD if the*-rdreleases are wanted). Note existing*-applicationPackage CRs arehelm.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.enabledgate for the hosted variant, or ship the preset withpaas/naasdisabled so the default converges.