Origin: oc apply does not work on objects created with a resourceVersion field

Created on 1 Jun 2018 · 20Comments · Source: openshift/origin

Related comment: https://github.com/openshift/release/pull/901#issuecomment-393963467

When creating an object via oc apply -f resource.yaml, subsequent patches to that object fail if the initial object in resource.yaml contained a metadata.resourceVersion field.

Example:

# given the following dc with a metadata.resourceVersion field, I will create it via oc apply
$ cat simpledc.yaml
---
apiVersion: v1
kind: DeploymentConfig
metadata:
  name: simple-dc
  creationTimestamp: null
  resourceVersion: "111"
  labels:
    name: test-deployment
spec:
  replicas: 1
  selector:
    name: test-deployment
  template:
    metadata:
      labels:
        name: test-deployment
    spec:
      containers:
      - image: openshift/origin-ruby-sample
        name: helloworld

$ oc apply -f simpledc.yaml
deploymentconfig.apps.openshift.io "simple-dc" created

# modify the original dc, removing the resourceVersion field
$ cat simpledc_modified.yaml
apiVersion: v1
kind: DeploymentConfig
metadata:
  name: simple-dc
  creationTimestamp: null
  labels:
    name: test-deployment
spec:
  replicas: 2
  selector:
    name: test-deployment
  template:
    metadata:
      labels:
        name: test-deployment
    spec:
      containers:
      - image: openshift/origin-ruby-sample
        name: helloworld

# attempt to run oc apply again
$ oc apply -f simpledc_modified.yaml
The deploymentconfigs "simple-dc" is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

If I run the steps above without setting a metadata.resourceVersion field when I create the dc via oc apply, I do not get the error seen, and the operation succeeds as expected.

Is this a bug, or an expected behavior of apply?

cc @stevekuznetsov @soltysh @liggitt

componencli componenkubernetes kinquestion lifecyclrotten prioritP1

Source

juanvallejo

👍1

Most helpful comment

I have the same error "metadata.resourceVersion: Invalid value: 0x0: must be specified for an update"
but in my case the dc does not contain resourceVersion parm at all!

Any update on this issue please?

aarthipa on 21 Feb 2019

👍3

All 20 comments

Is this a bug, or an expected behavior of apply?

I wonder if it's worth the hassle now that there's work upstream towards server-side apply.

soltysh on 5 Jun 2018

apply should likely do something better here, but creating with a resourceVersion to begin with is suspect

liggitt on 7 Jun 2018

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle stale

openshift-bot on 6 Sep 2018

/remove-lifecycle stale

soltysh on 6 Sep 2018

Issues go stale after 90d of inactivity.

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

/lifecycle stale

openshift-bot on 11 Dec 2018

/remove-lifecycle stale

soltysh on 19 Dec 2018

I have the same error "metadata.resourceVersion: Invalid value: 0x0: must be specified for an update"
but in my case the dc does not contain resourceVersion parm at all!

Any update on this issue please?

aarthipa on 21 Feb 2019

👍3

Same problem. Any workarounds?

Asgoret on 12 Apr 2019

👍1

Having same issue.

HomemBravo on 17 Apr 2019

+1 for this issue

Avni-Sharma on 16 May 2019

Issues go stale after 90d of inactivity.

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

/lifecycle stale

openshift-bot on 14 Aug 2019

/remove-lifecycle stale

dariodsa on 26 Aug 2019

It worked when I changed apply to replace, so you can try with it.

dariodsa on 27 Aug 2019

Issues go stale after 90d of inactivity.

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

/lifecycle stale

openshift-bot on 25 Nov 2019

/remove-lifecycle stale

teamdefinex on 25 Dec 2019

It worked when I changed apply to replace, so you can try with it.

"The imperative replace command replaces the existing spec with the newly provided one, dropping all changes to the object missing from the configuration file. This approach should not be used with resource types whose specs are updated independently of the configuration file."
It is not an alternative for apply.
We are still having the same issue.

teamdefinex on 25 Dec 2019

Issues go stale after 90d of inactivity.

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

/lifecycle stale

openshift-bot on 24 Mar 2020

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle rotten
/remove-lifecycle stale

openshift-bot on 23 Apr 2020

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift-bot on 23 May 2020

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

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