-
Bug
-
Resolution: Done
-
Major
-
None
-
2.7 GA
-
None
-
5
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
3scale 2019-11-25
APIcast breaks with APIAP and a second routing policy configured by the user.
In order for the defect to get activated, the Product must have at least one backend path defined, because that's the condition for APIAP to appear in the proxy config as rules of a "hidden" routing policy we are injecting.
The problem seems to derive from having in the config two routing policies, each one with its own set of rules and APIcast choosing the second one to apply.
Example of scenario how to reproduce it:
Summary
Product: APIAP + Routing policy (apiap-and-routing) Backends: [/gh → Github, /ip → ipinfo.io] Policies: [Route /ip → Echo] Order of the policies: APIAP → Routing → 3scale APIcast
Proxy config
apicast-config-apiap-routing-policy-sandbox-5.json
Requests
curl -k "https://apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net:443/gh/orgs/3scale?user_key=cdd309b92c05a9992e669ea8c8b930b6" 2019/11/27 11:06:30 [warn] 24#24: *13641 [lua] apicast.lua:65: upstream api for the service:4 is invalid, error:Upstream cannot be null, client: 10.131.3.224, server: _, request: "GET /gh/orgs/3scale?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1", host: "apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net" 2019/11/27 11:06:30 [warn] 24#24: *13641 [lua] apicast.lua:107: Upstream server not found for this request, client: 10.131.3.224, server: _, request: "GET /gh/orgs/3scale?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1", host: "apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net" 2019/11/27 11:06:30 [warn] 24#24: *13641 [lua] errors.lua:60: could not find upstream for service: 4, client: 10.131.3.224, server: _, request: "GET /gh/orgs/3scale?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1", host: "apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net" [27/Nov/2019:11:06:30 +0000] apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net:8080 10.131.3.224:46054 "GET /gh/orgs/3scale?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1" 404 5 (0.104) 0.064 curl -k "https://apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net:443/gh/users/guicassolato?user_key=cdd309b92c05a9992e669ea8c8b930b6" 2019/11/27 11:07:04 [warn] 24#24: *13653 [lua] apicast.lua:65: upstream api for the service:4 is invalid, error:Upstream cannot be null, client: 10.130.4.131, server: _, request: "GET /gh/users/guicassolato?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1", host: "apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net" 2019/11/27 11:07:04 [warn] 24#24: *13653 [lua] apicast.lua:107: Upstream server not found for this request while sending to client, client: 10.130.4.131, server: _, request: "GET /gh/users/guicassolato?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1", host: "apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net" 2019/11/27 11:07:04 [warn] 24#24: *13653 [lua] errors.lua:60: could not find upstream for service: 4 while sending to client, client: 10.130.4.131, server: _, request: "GET /gh/users/guicassolato?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1", host: "apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net" [27/Nov/2019:11:07:04 +0000] apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net:8080 10.130.4.131:40844 "GET /gh/users/guicassolato?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1" 404 5 (0.105) 0 curl -k "https://apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net:443/ip/2.139.235.79?user_key=cdd309b92c05a9992e669ea8c8b930b6" 2019/11/27 11:07:26 [warn] 24#24: *13663 [lua] apicast.lua:65: upstream api for the service:4 is invalid, error:Upstream cannot be null, client: 10.131.3.224, server: _, request: "GET /ip/2.139.235.79?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1", host: "apiap-and-routing-3scale-apicast-staging.20191125.apps.devel-ocp-41-ga.3sca.net" 2019/11/27 11:07:26 [error] 24#24: *13663 invalid URL prefix in " https://upstream" while sending to client, client: 10.131.3.224, server: _, request: "GET /ip/2.139.235.79?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1" [27/Nov/2019:11:07:26 +0000] _:8080 10.131.3.224:47170 "GET /ip/2.139.235.79?user_key=cdd309b92c05a9992e669ea8c8b930b6 HTTP/1.1" 500 174 (0.076) 0
According to the example above, it seems APIcast is applying the second routing policy in the chain (the one added by the user) and not the one injected by porta. Either way, applying only one of them while skipping the other means the costumers won't be able to add routing policies to Products, or APIAP won't work.
On porta side one thing that could be done is no longer hiding the injected routing policy of APIAP, but showing it instead to the user and allowing the user to add more rules to the policy config, as an alternative to adding a second routing policy. Considering the risk of users breaking APIAP behaviour, we also need to explore possible solutions on APIcast side.
We also need to discuss with Product (amasferr) about use cases for multiple routing policies in the same config. Does it even make sense? Remember about the several config possibilities of routing policies in general vs. how strict the one of APIAP is.
Dev note
Possible ways to solve for more than one routing policy
- Merge rules of each routing policy not one single routing policy
- Show APIAP routing policy in the UI and allow for the user to edit it
- Show APIAP routing policy in the UI as read-only and allow for the customer reorder
- relates to
-
-
- Closed
-