kubernetes: kubectl apply does not update ThirdPartyResource object.
I have a ThirdPartyResource object. The resource is as follows:
resource.yaml
metadata:
name: cron-tab.stable.example.com
apiVersion: extensions/v1beta1
kind: ThirdPartyResource
description: "A specification of a Pod to run on a cron style schedule"
versions:
- name: v1
- name: v2
crontab.yaml
apiVersion: "stable.example.com/v1"
kind: "CronTab"
metadata:
name: hello-world
cronSpec: "*/1 * * * *"
image: hello-world
I create the resource and object
$ kubectl create -f resource.yaml
$ kubectl create -f crontab.yaml
However, when I run apply I fails to update the properties.
$ cat crontab.yaml
apiVersion: "stable.example.com/v1"
kind: "CronTab"
metadata:
name: hello-world
cronSpec: "*/5 * * * *"
image: hello-world
$ kubectl apply -f crontab.yaml
crontab "hello-world" configured
kubectl is sending a request to the API and if I watch the object I get a modified event but it is still the old value. Getting the object also returns the old value.
$ kubectl get crontab hello-world -o json | jq '.cronSpec'
"*/1 * * * *"
I suspect that kubectl is not diffing the object properly and neglects to send the updated object JSON data.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 7
- Comments: 36 (26 by maintainers)
Commits related to this issue
- Use kubectl apply in custom service example deploy https://github.com/kubernetes/kubernetes/issues/29542 has been fixed, use apply instead of create to create third party resources in custom service... — committed to Tapppi/prometheus-operator by Tapppi 7 years ago
- Use kubectl apply in custom service example deploy https://github.com/kubernetes/kubernetes/issues/29542 has been fixed, use apply instead of create to create third party resources in custom service... — committed to metalmatze/kube-prometheus by Tapppi 7 years ago
fixed in #40666
@foxish @AdoHe
This is going to affect anyone using TPR (we develop etcd operator for example) pretty hard. This is a bug, and I feel we should fix this in 1.5.
/cc @brendandburns
@hjacobs https://github.com/coreos/etcd-operator/blob/master/README.md#resize-an-etcd-cluster has an example of the workaround.