Description of problem: When I make a route for my website and I try to open it the hostname, it brings me to a page saying "application is not available" even though there are no errors and everything seems to be fine. Version-Release number of selected component (if applicable): 1.0.0 How reproducible: You just need to open the current hostname set for my route which is the default hostname that openshift gave me. Steps to Reproduce: 1. 2. 3. Actual results: When I open the link it shows me a page saying "application is not available" Expected results: My website should open when I use that hostname instead of giving me an error Additional info:
*** Bug 1449437 has been marked as a duplicate of this bug. ***
Hi Leo, Thanks for submitting this bug. Have you tried both HTTP and HTTPS? Sometimes this can happen if your application listens only on HTTPS but you try to access the route over HTTP. If you have a Readiness Probe configured, check to make sure that the platform successfully determines that your application is ready to serve requests. You can also use "oc port-forward" to tunnel directly from your local machine to the backing service, to make sure that your application is running as expected. Cheers, Jonathan
Also, can you provide your application URL and your route/hostname?
Hi all! I had this problem on new deployment, but it disappeared after a few minutes. Now I have it on every application update (when I push something to github). Everything is green, the pod is reported as ready, the application (python + flask, if it matters) is started according to its logs, but "Application not available" for several minutes every time. My app is http://dashboard-ironic.7e14.starter-us-west-2.openshiftapps.com/ and will hopefully get back up when you see it :)
Hello Openshift-Online Team, looks like, that I am experiencing the same or similar issue. I am on starter-us-west-2 and the symptoms I could observe are: 1. After deployment and setting up a route everything looks fine in Openshift. 2. Some HTTP/HTTPS requests work as expected, but around 70 percent of the requests will get an "HTTP/1.0 503 Service Unavailable" / "Application is not available". 3. It looks like the issue does not depend on a specific application. It happens with my own ElasticSearch container but also with a quick and dirty PHP sample app. 4. HTTP or HTTPS does not matter. 5. The problem still exists even when no fresh deployment happens for hours. Short testcase showing how it looks like: $ for i in {0..10}; do curl -sI "http://bar-foo.7e14.starter-us-west-2.openshiftapps.com/" | grep HTTP; done HTTP/1.0 503 Service Unavailable HTTP/1.1 200 OK HTTP/1.0 503 Service Unavailable HTTP/1.1 200 OK HTTP/1.0 503 Service Unavailable HTTP/1.0 503 Service Unavailable HTTP/1.1 200 OK HTTP/1.0 503 Service Unavailable HTTP/1.0 503 Service Unavailable HTTP/1.1 200 OK HTTP/1.0 503 Service Unavailable Hope you can help us with that issue. If you need more information and details to track down the problem. Please let me know... Best Regards Frank
Hi Frank, It looks like this was an intermittent issue on Starter clusters. This should now be resolved. Can you confirm that you're no longer having this issue?
Hello Will, yes I can confirm that, I just checked it and my issue is resolved... thanks for your help! Best Regards Frank
The issue on starter-us-west-2 is fixed. $ for i in {1..20}; do curl -sI http://django-psql-persistent-yasun-prod01-1.7e14.starter-us-west-2.openshiftapps.com|grep HTTP ; done HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK ... ... HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK