Create API proxy between 3scale and multiple cloudigrade environments
Summary
As a cloudigrade developer, I want to keep having dynamic review environments even though 3scale wants only one environment per OSD project.
In order to accomplish this, we have discussed having 3scale direct its traffic to a proxy of our own design which in turn directs its traffic to multiple possible backend API environments.
Acceptance Criteria
-
Verify proxy uses HTTP headers to determine which backend API environment should be used -
Verify proxy appropriately rewrites the request for a backend API -
Verify this proxy is configured such that in general: - requests with no
X-4Scale-Env
header value route to our "Cloudigrade Prod" project - requests with
X-4Scale-Env:stage
header route to our "Cloudigrade Stage" project - requests with
X-4Scale-Env:qa
header route to our "Cloudigrade Test" project - requests with
X-4Scale-Env:ci
header route to review environments in our "cloudigrade-qa" project
- requests with no
Assumptions and Questions
- This is probably just an nginx config with some wildcard pattern-matching proxy+rewrite logic.
- Instead of URL slugs, can this be an extra HTTP header? Let's double-check that 3scale doesn't filter any headers that we might want to use.
- Where should this nginx configuration live? With cloudigrade repo itself or another repo?
- yes, let's put this in another repo that is just configs and a Dockerfile.
- Implementation detail for whoever picks this up: URL slug or HTTP header.
- Technically we do not need the proxy in prod (because it's 1:1) or in ci (because we don't have a specific ci), but we should just be consistent everywhere.
- In the future, maybe this proxy can serve "unavailable" page whenever we have downtime, but not required as part of this story.
Edited by Brad Smith