Bug 1785360 - [OVN] application does not unidle
Summary: [OVN] application does not unidle
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.5.0
Assignee: Tim Rozet
QA Contact: Ross Brattain
URL:
Whiteboard:
: 1801780 (view as bug list)
Depends On:
Blocks: 1812395 1812396
TreeView+ depends on / blocked
 
Reported: 2019-12-19 18:43 UTC by Ross Brattain
Modified: 2020-07-13 17:13 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1812395 1812396 (view as bug list)
Environment:
Last Closed: 2020-07-13 17:12:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:2409 0 None None None 2020-07-13 17:13:19 UTC

Description Ross Brattain 2019-12-19 18:43:39 UTC
Description of problem:

Unidling is not working with OVN


Version-Release number of selected component (if applicable):

4.3.0-0.nightly-2019-12-19-105827

How reproducible:

always

Steps to Reproduce:

1. create test pods/svc
# oc new-project test
# oc create -f https://raw.githubusercontent.com/anuragthehatter/v3-testfiles/master/networking/list_for_pods.json 
# oc create -f https://raw.githubusercontent.com/anuragthehatter/v3-testfiles/master/networking/pod-for-ping.json 

2. Makes sure pods and services are running
# oc get pods

3. check service
# oc get svc
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
test-service   ClusterIP   172.30.33.132   <none>        27017/TCP   165m

	
3. Now idle the test service like
# oc idle test-service
	
4. Check pods again to make sure they are terminating due to step 3

# oc get pods

	
5. Now from the test pod "hello-pod", curl to the service ip

# oc rsh hello-pod
/ # curl $SERVICE:$SERVICE_PORT
Hello OpenShift!
/ # exit

6. Check the pods again and make sure they are being recreated due to unidling of svc
# oc get pods


Actual results:

curl: (7) Failed to connect to x.x.x.x port 27017: Operation timed out                                                                                                                                          
/ # command terminated with exit code 7

no test-rc pods are running


Expected results:

curl outputs "Hello OpenShift!"

two test-rc pods are running

Additional info:

Comment 2 Stephen Cuppett 2019-12-19 18:54:02 UTC
Moving this to our active development branch (4.4.0) for Target. Fixes, if any, which require backporting to earlier releases will result in cloned BZs for those releases.

Comment 3 Casey Callendrello 2019-12-20 09:11:06 UTC
I'm inclined to kick this out to 4.4 - I doubt we'll get to this in time.

Comment 4 Ross Brattain 2020-02-06 02:55:25 UTC
reproduced on 4.4.0-0.nightly-2020-02-04-122053

Comment 5 zhaozhanqi 2020-02-12 07:16:21 UTC
*** Bug 1801780 has been marked as a duplicate of this bug. ***

Comment 8 Tim Rozet 2020-04-14 17:11:27 UTC
Hey Ross,
Can you retest this and see if it still happens with latest 4.5? I just tried in my setup and I see that k8s gets the right event when traffic hits the idled service:
[trozet@trozet hack]$ kubectl get events -A
NAMESPACE          LAST SEEN   TYPE      REASON        OBJECT                                  MESSAGE
default            1s          Normal    NeedPods      service/test-service                    The service test-service needs pods

Thanks.

Comment 9 Ross Brattain 2020-04-14 19:59:23 UTC
Unable to reproduce on 4.5.0-0.nightly-2020-04-14-084836 with ~10 seconds timeout after connecting to idled service.  From testing it looks like it takes at least 7 seconds to unidle a service.

Updated the automation to use a 30 second timeout after triggering unidle, hopefully 30 seconds is sufficient.

Comment 12 errata-xmlrpc 2020-07-13 17:12:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2409


Note You need to log in before you can comment on or make changes to this bug.