Description of problem: If you idle a simple web application, e.g. cakephp sample, the following behavior occurs. First HTTP request is "held", in accordance with idling documentation, until the pod is spun up and becomes active, and then the request is passed to the service. However, if you make multiple HTTP requests, only the first is held, but while the application is spinning up, the subsequent requests received the "Application is not available" page. We believe this to be because the "idling" annotation/process recognizes that the request needs to be held, but the subsequent requests are simply hitting a pod that has not yet started/passed it's readiness checks yet, and are thus treated as normal requests hitting a pod that hasn't started, which is the "Application is not available" page. Version-Release number of selected component (if applicable): 3.7 How reproducible: Confirmed Steps to Reproduce/Actual results: # oc idle ruby-ex The service "scc/ruby-ex" has been marked as idled ... $ oc get po NAME READY STATUS RESTARTS AGE ruby-ex-1-build 0/1 Completed 0 22m Now, in two terminal windows I run this same command: # curl -kv ruby-ex-scc.apps.mamonaku.quicklab.rdu2.cee.redhat.com When using TCP readiness checks, in the first window I get: > Accept: */* > * Empty reply from server * Connection #1 to host ruby-ex-scc.apps.mamonaku.quicklab.rdu2.cee.redhat.com left intact curl: (52) Empty reply from server It then returns. While its waiting, though, curls in the other terminal get "Application is not available". Using HTTP readiness checks results in the first terminal getting the actual output. Expected results: This is sort of expected, since from the router's perspective there are just 0 pods running. But better behavior would be that we hold an "idled" flag until a pod is fully spun up, so that ALL connections are saved. Additional info:
*** Bug 1567043 has been marked as a duplicate of this bug. ***
This can't be fixed until the new object-based unidling code lands since there is no way to distinguish the states during undling. It is targeted for 3.11. See: https://github.com/openshift/origin/pull/19205
(In reply to Ben Bennett from comment #3) > This can't be fixed until the new object-based unidling code lands since > there is no way to distinguish the states during undling. It is targeted > for 3.11. > > See: https://github.com/openshift/origin/pull/19205 Does this mean that the bug is fixed with the merge of the linked refactor, or 19205 must land before a fix can be implemented as a followup?
This bug will be fixed when the https://github.com/openshift/origin/pull/19205 lands.
The API changes required to support this fix are not going to be available until 4.0 at the earliest. As a result I'm targeting a fix for version 4.1.
We don't think this is going to be addressed in OpenShift 3. I'm going to close the bug. If circumstances change, we can of course re-open it.