Open thockin opened 1 year ago
@thockin: 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.
If the apiserver gave you a clue like "this field doesn't like to be PATCHed" - could kubectl fall back on PUT?
@thockin What do you have in mind here? Would apiserver be able to tell us that we need to retry with PUT? And what would that look like?
/triage needs-information
In theory, we could add it to something like the OpenAPI, so that you could look at a patch and say "oh, this won't work, let's fall back on PUT" or even just throw an error like "apply uses PATCH and this operation modifies a field which doesn't like to be patched - consider kubectl replace
instead".
Before we go designing that API machinery, I wanted to see if I was just being dumb and there's some reason we would not be able to do it.
How will this interact with our (potential? confirmed?) plan to deprecate and remove client-side apply?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues 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
/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.
This bot triages un-triaged issues 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
Do we think that this is something that would cause issues for downstream users? I agree that this could be useful for people that interact directly with kubectl but I'm thinking of automated systems that may expect a failure due to expected client side behavior. I can imagine some solutions to get around this (kuberc) but just want to gauge if people think this would be a real problem or if we could just shove it directly into kubectl.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues 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
/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.
This bot triages un-triaged issues 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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues 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
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues 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
There's an ancient issue with Service ports having an insufficient merge key for client-side apply. This causes a lot of pain for people who try to
kubectl apply
orkubectl edit
a Service.If the apiserver gave you a clue like "this field doesn't like to be PATCHed" - could kubectl fall back on PUT?