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

[nightfury1204]

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.

[tamalsaha]

/kind bug
/sig cli

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[flyer103]

Related to kubernetes/kubernetes#60845

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[coderanger]

/remove-lifecycle rotten

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[seans3]

/remove-lifecycle stale
/area kubectl

[seans3]

/priority P2

[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).

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[florianrusch]

/remove-lifecycle rotten

[florianrusch]

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.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

Created kubernetes/kubernetes#99556 as a POC to get initial feedback

[eddiezane]

/unassign @eddiezane @seans3
/assign @nikhita

[aojea]

/cc

[nathanperkins]

What's the best workaround for this issue? I could use a client library to write it in go but that seems a bit heavy handed.

[nikhita]

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

[gtfortytwo]

@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 .

[silentred]

@nikhita waiting for this feature +1

[AlekSi]

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

[Ruoyu-y]

Any timeline for this one?

[nikhita]

kubernetes/kubernetes#99556 has merged and subresource support will be present in Kubernetes v1.24.

[brianpursley]

@nikhita Does kubernetes/kubernetes#99556 close this issue?

[danopia]

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 #564 (comment) this is intended behavior.

[nikhita]

@danopia thanks for summarizing it well!

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 #564 (comment) this is intended behavior.

This is correct. The main resource endpoint will ignore all changes in the status subpath, so --subresource needs to be explicitly specified if you need to edit the status section.

Closing since kubernetes/kubernetes#99556 fixes the issue.
/close

[k8s-ci-robot]

@nikhita: Closing this issue.

In response to this:

@danopia thanks for summarizing it well!

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 #564 (comment) this is intended behavior.

This is correct. The main resource endpoint will ignore all changes in the status subpath, so --subresource needs to be explicitly specified if you need to edit the status section.

Closing since kubernetes/kubernetes#99556 fixes the issue.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fengyinqiao]

kubernetes/kubernetes#99556 has merged and subresource support will be present in Kubernetes v1.24.

@nikhita can I use kubectl v1.24 but server still keep v1.11 or v1.18?(this two version are on my production now, hard to upgrade)