Open Arabus opened 2 years ago
@Arabus: This issue is currently awaiting triage.
SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted
label.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
Partially responsible for roboll/helmfile#2031
Would be nice to receive some feedback on this e.g., why kustomize still uses the v4 version of that lib
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
Would be nice to receive some feedback on this e.g., why kustomize still uses the v4 version of that lib
While I'm not sure a bump has been explicitly considered, the barrier to upgrading would be behaviour parity with kubectl, which kustomize is embedded in (see kubectl patch --type json
behaviour). As much as the maintainers would like to have the standards-compliant behaviour in theory, this would be a breaking change for our users. Kubectl so far has not upgraded following the discussion in https://github.com/kubernetes/kubernetes/pull/91622. On the Kustomize side, I think we have more freedom to do this in theory, but we would need to get buy-in for brining in the newer dependency to kubectl, and we would to make the change part of a major version release. As such, I'll add this issue to the Kustomize v5 project for consideration.
/triage under-consideration
Upon further investigation, we are going to need to wait for kubectl to pick up the version bump before we can do so, as having two versions in use in kubernetes/kubernetes has been deemed unacceptable in existing conversations I found. I will keep this issue open and tracked in the "major version bumps" project to ensure we periodically revisit whether this is possible yet. See also https://github.com/kubernetes/kubernetes/pull/113092 for example.
Describe the bug
When running
kustomize build
with a patchesJson6902 patch to replace a value on a location not present at the given target, kustomize adds it. This is unexpected behaviour, violates https://datatracker.ietf.org/doc/html/rfc6902/#section-4.3 and should result in an Error instead.Files that can reproduce the issue
kustomization.yaml
jsonpatches/patch.0.yaml
templates/resources.yaml
Expected output
Some kind of error stating that replacing a missing value is not supported
Actual output
Kustomize version
Platform
Additional context
The problem seems to haven been fixed in the upstream library kustomize uses, see https://github.com/evanphx/json-patch/issues/119 at the end. It might be suitable to bump the used version to v5 to solve this issue