Description of problem: After creating a trivial app, I am unable to access it via its exposed route. Version-Release number of selected component (if applicable): oc v3.6.106 kubernetes v1.6.1+5115d708d7 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://internal.api.free-int.openshift.com:443 openshift v3.6.106 kubernetes v1.6.1+5115d708d7 How reproducible: 100% Steps to Reproduce: 1. oc delete --ignore-not-found project aos-cd-smoke-test-proj 2. oc new-project aos-cd-smoke-test-proj 3. oc new-app --image-stream=ruby --code=https://github.com/openshift/ruby-hello-world 4. oc logs -f bc/ruby-hello-world 5. oc expose svc/ruby-hello-world 6. oc get routes 7. Access the route with a browser Actual results: Hitting the URL (e.g. http://ruby-hello-world-aos-cd-smoke-test-proj.d800.free-int.openshiftapps.com/) reports: ----------------------- Application is not available The application is currently not serving requests at this endpoint. It may not have been started or is still starting. ... ----------------------- Expected results: The same process on another cluster with a slightly older oc level displays a "Welcome to an OpenShift v3 Demo App!" welcome message. Additional info:
jupierce and I hopped on the box to troubleshoot, and since we see reencrypt routes with no certs, and no matching cert written to disk... I suspect the culprit is in https://github.com/openshift/origin/pull/13752 somewhere. It would help to have the output from 'oc get dc router -o yaml' as an attachment to the case. Thanks.
Justin, can you please add the router log 'oc log router-...' to the bug.
The routes are available now except for reencrypt route. free int: openshift v3.6.116 kubernetes v1.6.1+5115d708d7
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1461378 https://bugzilla.redhat.com/show_bug.cgi?id=1462709 You need https://github.com/openshift/origin/pull/13752 to make reencrypt routes work with your template. Without that the router is crashing when someone makes a reencrypt route without a destiantion cert.
Go ahead and assign this to me, I'm going to make the oapi/v1 API backwards compatible in this case.
*** Bug 1461378 has been marked as a duplicate of this bug. ***
https://github.com/openshift/origin/pull/14818
@Clayton Coleman @Justin Pierce @Ben Bennett @Eric Paris @zzhao We try to reproduce the problem in the devenv with free int router image , but the problem did not occur after creating and deleting the re-encrypt route with or without the destination ca cert.So could you possibly provide some help to reproduce this problem so that we could have a criterion to judge whether the bug was fixed? The steps: 1. Launch the devenv with free int router image: # ansible-playbook -i hosts devenv-launch.yml -e DEVENV=free Modify the router image in dc: registry.ops.openshift.com/openshift3/ose-haproxy-router:v3.6.116 2. Create a pod , a svc, and edge, passthrough, re-encrypt routes with or without destination ca cert: # oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/caddy-docker.json # oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/edge/service_unsecure.json # oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/reencrypt/service_secure.json # oc create route reencrypt reenroute--service=service_secure # oc create route passthrough passroute --service=service_secure # oc create route edge edgeroute--service=unservice_secure # wget https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/reencrypt/route_reencrypt_dest.ca # oc create route reencrypt reencroute --service=service_secure --dest-ca-cert=route_reencrypt_dest.ca # oc delete route reenroute reencroute 3. After the re-encrypt routes are created and deleted for many times, the errors like comment 9 are not found in the logs of router , but if we delete the destination ca cert in the router pod, the errors will be seen but the router can be running normally if accessing some other routes ,e.g: passthrough or edge.
since this bug did not found for free-int. so verified this bug