Description of problem: F5 router cannot create the rule for route with the "path: /" so user cannot access the route via F5. Adding "path: /" to route or update the path from "path: /other-path" to "path: /" also failed. Version-Release number of selected component (if applicable): openshift v3.5.0.19+199197c kubernetes v1.5.2+43a9be4 etcd 3.1.0 How reproducible: always Steps to Reproduce: 1. create F5 router 2. create project,pod,svc and route. #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/edge/route_edge.json 3. oc edit route and add path "/" to the route # oc get route -n u2p2 NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD secured-edge-route test-edge.example.com / service-unsecure <all> edge None Actual results: the route cannot be accessed via F5 and error logs as below: E0213 02:25:39.328313 1 controller.go:311] Encountered an error on POST request to URL https://10.66.144.115/mgmt/tm/ltm/policy/openshift_secure_routes/rules/openshift_route_u2p2_secured-edge-route/conditions: HTTP code: 400; error from F5: 01071709:3: Policy '/Common/openshift_secure_routes', rule 'openshift_route_u2p2_secured-edge-route'; operand 'http-uri' with condition 'equals' requires at least 1 value. Expected results: f5 should support the route with path "/" Additional info:
https://github.com/openshift/origin/pull/12944
Verified in OCP v3.5.0.26-1+da1be19, there is no error messages in router pod and can create rule for path "/", but it has different behave compare to haproxy. When using path /, both "http://url/" and "http://url/path/" can be accessed on F5 router; but only the former can be accessed if on haproxy router. It should keep same behave on both F5 and haproxy, I think.
This has been merged into ocp and is in OCP v3.5.0.21 or newer.
Regarding comment#2, it is because for an empty path "/", we end up ignoring the whole thing and tell F5 that base condition for the rule is '(any)'. We can work with F5 to find out what is the best possible way to ensure an empty path enforcement. I don't think it is a bug (the deviation from haproxy behaviour) but possibly an RFE to emulate specific behaviour. File an RFE bug maybe?
verified in OCP openshift v3.5.0.26-1+da1be19 and according above comments, the issue has been fixed.
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-2017:0884