livestate.loadManifests ignores per-target KustomizeVersion and KustomizeOptions
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 1.4k
- Forks
- 364
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 84
Description
What happened
The multicluster livestate plugin ignores per-target KustomizeVersion and KustomizeOptions overrides defined in multiTargets.
While the deployment plugin applies these per-target overrides before constructing provider.LoaderInput, the livestate implementation always uses the top-level values from spec.Input.
As a result, deployment and livestate may render manifests using different Kustomize versions or options for the same target, which can lead to inconsistent manifest rendering and potentially incorrect drift/sync calculations.
This appears to be another divergence between the deployment and livestate implementations. PR #6783 already addressed kustomizeDir and tracking labels, but KustomizeVersion and KustomizeOptions are still not handled in the same way.
What you expected to happen
livestate.loadManifests() should apply the same precedence as the deployment implementation:
- Use the top-level
KustomizeVersionandKustomizeOptionsby default. - Override them with
multiTarget.KustomizeVersionwhen specified. - Override them with
multiTarget.KustomizeOptionswhen specified.
This would ensure that deployment and livestate render manifests consistently for the same target.
How to reproduce it
- Create a Kubernetes Multicluster application.
- Configure a top-level
kustomizeVersion(orkustomizeOptions). - Configure one
multiTargetwith differentkustomizeVersionand/orkustomizeOptions. - Run a deployment and observe that the deployment path uses the per-target overrides.
- Run livestate for the same application.
- Observe that the livestate path still uses the top-level values instead of the per-target overrides.
From the current implementation:
deployment/loadManifests()appliesmultiTarget.KustomizeVersionandmultiTarget.KustomizeOptions.livestate/loadManifests()always passesspec.Input.KustomizeVersionandspec.Input.KustomizeOptionsdirectly toprovider.LoaderInput.
Environment
-
piped version: master (current HEAD)
-
control-plane version: N/A
-
Others:
- Related PR: #6783 ("fix(kubernetes_multicluster): stamp tracking labels and honour kustomizeDir in livestate loadManifests"), which fixed
kustomizeDirparity but does not apply the same per-target precedence forKustomizeVersionandKustomizeOptions.
- Related PR: #6783 ("fix(kubernetes_multicluster): stamp tracking labels and honour kustomizeDir in livestate loadManifests"), which fixed
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing deployment/loadManifests() with livestate/loadManifests(), focusing on how each constructs provider.LoaderInput. Trace the top-level and multiTarget KustomizeVersion and KustomizeOptions values, then verify the livestate path follows the documented precedence for a target with overrides. Done means deployment and livestate use the same effective values for each target.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 70/100