Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-4016

APIAP + second routing policy breaks apicast

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • None
    • 2.7 GA
    • System
    • None
    • 5
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • 3scale 2019-11-25

    Description

      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

      1. Merge rules of each routing policy not one single routing policy
      2. Show APIAP routing policy in the UI and allow for the user to edit it
      3. Show APIAP routing policy in the UI as read-only and allow for the customer reorder

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              mcassola Guilherme Cassolato
              Guilherme Cassolato Guilherme Cassolato
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: