kubectl: kubectl edit or apply can not update .status when status sub resource is enabled

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version): Client Version: version.Info{Major:“1”, Minor:“12”, GitVersion:“v1.12.0”, GitCommit:“0ed33881dc4355495f623c6f22e7dd0b7632b7c0”, GitTreeState:“clean”, BuildDate:“2018-09-27T17:05:32Z”, GoVersion:“go1.10.4”, Compiler:“gc”, Platform:“linux/amd64”} Server Version: version.Info{Major:“1”, Minor:“11”, GitVersion:“v1.11.3”, GitCommit:“a4529464e4629c21224b3d52edfe0ea91b072862”, GitTreeState:“clean”, BuildDate:“2018-09-09T17:53:03Z”, GoVersion:“go1.10.3”, Compiler:“gc”, Platform:“linux/amd64”}

Environment:

minikube

What happened: I have a crd that has status subresource is enabled. When i edit the status of the crd using kubectl edit, the changes doesn’t apply.

What you expected to happen: kubectl edit should apply the changes in status field.

How to reproduce it (as minimally and precisely as possible):

$ cat customresourcedefination.yaml 
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: foos.try.com
spec:
  group: try.com
  version: v1alpha1
  scope: Namespaced
  subresources:
    status: {}
  names:
    plural: foos
    singular: foo
    kind: Foo

$ kubectl apply -f customresourcedefination.yaml

$ cat foo.yaml 
apiVersion: try.com/v1alpha1
kind: Foo
metadata:
  name: my-foo
status:
  hello: world

$ kubectl apply -f foo.yaml

# edit the status
$ kubectl edit foo/my-foo

Anything else we need to know: If status subresource is disabled for crd, then kubectl edit works fine.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 38
Comments: 46 (27 by maintainers)

Links to this issue

kubernetes - kubectl patch doesn't update status subresource - Stack Overflow

Commits related to this issue

[EPMDEDP-5982]: Remove status subresource section from codebasebranch CRD Patch doesn't work with this section. Related issues: https://github.com/kubernetes/kubectl/issues/564 https://github.com/ku... — committed to epam/edp-codebase-operator by deleted user 3 years ago
[EPMDEDP-5982]: Remove status subresource section from codebasebranch CRD Bump version Patch doesn't work with this section. Related issues: https://github.com/kubernetes/kubectl/issues/564 https://g... — committed to epam/edp-codebase-operator by deleted user 3 years ago
Switchover implementation in PGK The switchover procedure is entirely handled by PGK and not guided by the operator. PGK during its reconciliation cycle will look for changes in the `targetPrimary` ... — committed to cloudnative-pg/cloudnative-pg by leonardoce 4 years ago

Most upvoted comments

From @DBarthe

I guess this is intended behavior according to the design proposal :

If the /status subresource is enabled, the following behaviors change:

The main resource endpoint will ignore all changes in the status subpath. (note: it will not reject requests which try to change the status, following the existing semantics of other resources).

Wouldn’t it be nice if we could change the status field in some kind with kubectl? Maybe with an extra command like: kubectl edit foo/status my-foo or kubectl edit foo.status my-foo. I’m not sure if there is any convention on how this kind of commands should look like.

Our use-case: We’ve built an operator (shell-operator) for our CRDs and would like to edit the status field with kubectl within this operator.

+36

florianrusch on Nov 27, 2019

I hate to be That Guy that reopens issues, but this is a major gap for manual testing and scripting.

+33

thockin on Apr 29, 2020

https://github.com/kubernetes/kubernetes/pull/99556 has merged and subresource support will be present in Kubernetes v1.24.

+17

nikhita on Mar 25, 2022

I think the issue here is that there seems to be no way to use kubectl to edit a status?

E.g something like kubectl edit pod --status foo or kubectl edit pod --subresource=status or something like that.

On Wed, Apr 29, 2020 at 9:24 AM Kubernetes Prow Robot notifications@github.com wrote:

Closed #564.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

thockin on Apr 29, 2020

Created https://github.com/kubernetes/kubernetes/pull/99556 as a POC to get initial feedback

nikhita on Feb 28, 2021

Looks like this thread staled out a bit…

I tried the new flag out with kubectl v1.25.4 and kubectl edit --subresource=status works to edit the status section. Nice!

As a quick recap: the original reproduction from the top of this thread is still unchanged. If you don’t use --subresource and try changing status, those changes will still be silently dropped. As per https://github.com/kubernetes/kubectl/issues/564#issuecomment-621318565 this is intended behavior.

danopia on Jan 3, 2023

this seems higher priority than P2 to me

liggitt on May 6, 2020

I guess this is intended behavior according to the design proposal :

If the /status subresource is enabled, the following behaviors change:

The main resource endpoint will ignore all changes in the status subpath. (note: it will not reject requests which try to change the status, following the existing semantics of other resources).

DBarthe on Jul 26, 2019

https://github.com/ulucinar/kubectl-edit-status plugin can be used in the meantime.

AlekSi on Sep 8, 2021

@nathanperkins This feature is planned for v1.22 - https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource

nikhita on Jun 17, 2021

/remove-kind bug /kind feature

I agree this is a really annoying gap. Adding --subresource support for get/edit/apply/patch commands would make sense to me.

xref an attempt to do this at https://github.com/kubernetes/kubernetes/pull/60902 and a need for it at https://github.com/kubernetes/kubernetes/issues/15858#issuecomment-624686815

liggitt on May 6, 2020

@nathanperkins This feature is planned for v1.22 - https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource

Since it appears this did not make it into v1.22 , do you have any idea of an updated timeline, @nikhita ? Our use case is similar to that mentioned by @florianrusch .

gtfortytwo on Aug 29, 2021

SIG CLI meeting on May 20th agreed to move forward on this and prioritize it. As work on this progresses, we’d like to get feedback from the larger community.

/assign /assign @eddiezane

seans3 on May 20, 2020