Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1285702

Summary: "--grace-period" option does not take effect for oc replace
Product: OpenShift Container Platform Reporter: Xingxing Xia <xxia>
Component: NodeAssignee: Jan Chaloupka <jchaloup>
Status: CLOSED CURRENTRELEASE QA Contact: Jianwei Hou <jhou>
Severity: low Docs Contact:
Priority: medium    
Version: unspecifiedCC: aos-bugs, ccoleman, gblomqui, jokerman, mmccomas, xxia
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-03 14:54:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Xingxing Xia 2015-11-26 10:09:49 UTC
Description of problem:
Seems "--grace-period" is ignored and does not take effect.

Version-Release number of selected component (if applicable):
openshift/oc v1.1-218-g42c0867
kubernetes v1.1.0-origin-1107-g4c8e6f4


How reproducible:
Always

Steps to Reproduce:
1. Create a pod
$ oc run mypod --image=yapei/hello-openshift  --generator=run-pod/v1
2. Prepare a pod .json file
$ oc export pod mypod -o json > mypod.json
3. oc replace with "--grace-period", set the time as 100 seconds
$ oc replace -f mypod.json --force --grace-period=100
pod "mypod" deleted
Error from server: pods "mypod" already exists

Actual results:
3. Error from server: pods "mypod" already exists

Expected results:
3. The "--grace-period" should take effect.


Additional info:
Although the output says 'pod "mypod" deleted', in fact, the pod "mypod" is being terminated. 
For more info, see "oc replace -h"

Comment 1 Andy Goldstein 2016-05-18 16:32:34 UTC
Is your expectation that 'oc replace' should wait for the deleted resource to actually be deleted (respecting grace period) before it should attempt to create the replacement resource?

Is this still happening in the latest version of Origin?

Comment 2 Xingxing Xia 2016-05-19 08:10:04 UTC
(In reply to Andy Goldstein from comment #1)
> Is your expectation that 'oc replace' should wait for the deleted resource
> to actually be deleted (respecting grace period) before it should attempt to
> create the replacement resource?
> 
> Is this still happening in the latest version of Origin?

Yes, that is my expectation.
This bug still reproduces when testing with:
$ openshift version
openshift v1.3.0-alpha.0-586-gcd9ea84
kubernetes v1.3.0-alpha.1-331-g0522e63
etcd 2.3.0

Comment 3 Andy Goldstein 2016-05-27 13:41:17 UTC
Clayton, any insight on the behavior here?

Comment 4 Jan Chaloupka 2016-06-27 12:53:58 UTC
# oc version
oc v1.3.0-alpha.2-260-g1b04cb2
kubernetes v1.3.0-alpha.3-599-g2746284

Still reproducible with. On debugging.

Comment 5 Jan Chaloupka 2016-06-27 13:55:42 UTC
Will have to dig more into the request builder. However,

1) the replace first deletes the pod
2) the replace does not wait for pod to be deleted (if the grace-period is set)
3) the replace wants to create a pod with the same name which is not possible is the name is still used

Still, what should be the default behaviour of the replace command? If you set the grace period to 5s, the replace command can wait for 5 second and then request for a pod to be created. However, if you choose the period 1h, the replace command will hang for an hour before it sends a request for a new pod.

I don't think the replace command was designed to work with grace period.

Any thoughts?

Comment 6 Jan Chaloupka 2016-06-27 14:15:16 UTC
IIRC, in the earlier times of k8s, the pod was deleted right away (just guessing). Anyway, the is not related to --grace-period at all. You will end up in the same situation just with ``oc replace -f mypod.json --force``.

Comment 7 Jan Chaloupka 2016-06-27 14:28:56 UTC
pod "mypod" deleted
Error from server: pods "mypod" already exists

occurs only when you use the --force option.

Comment 8 Jan Chaloupka 2016-06-27 14:35:40 UTC
Reproducible in the master HEAD of kubernetes as well.

Comment 9 Jan Chaloupka 2016-06-27 14:44:46 UTC
Upstream issue reported [1]. This bug consists of two parts:

1). make the --force option work again
2). make the --force option work with --grace-period

[1] https://github.com/kubernetes/kubernetes/issues/28115

Comment 10 Jan Chaloupka 2016-10-18 10:38:41 UTC
Fixed upstream.

Comment 11 Jan Chaloupka 2016-10-18 10:40:37 UTC
https://github.com/kubernetes/kubernetes/pull/31841

Comment 12 Greg Blomquist 2019-07-03 14:54:23 UTC
PR from comment #11 merged ~3 years ago

Comment 13 Red Hat Bugzilla 2023-09-14 03:13:51 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days