Geo: MVP proposals for secondary mimicry
Problem to solve
The prerequisite for a single URL for multiple Geo nodes is: Secondary nodes must behave like the primary. &1466 (closed)
Put another way, any request sent to a secondary must result in the same side effects and the same output.
Intended users
Further details
Related issues/epics:
Proposal: Redirect almost everything
- On secondary nodes, redirect almost all HTTP requests to the primary except for:
- Git requests (these are already handled elsewhere)
- Some Admin things, especially
Admin Area > Geo
and the OAuth stuff necessary for viewing a secondary's Admin Area
- On the primary,
Admin Area > Geo > Nodes
addAdmin Area
buttons which link to each secondary node's Admin Area
You still need 2 user-facing URLs:
gitlab.example.com
gitlab-primary.example.com
UI and API interactions all end up happening at gitlab-primary.example.com
, but gitlab.example.com
works for everything that follows redirects. This proposal is relatively low weight, I think.
Proposal: Proxy almost everything
- On secondary nodes, proxy all HTTP requests to the primary:
- Including Git pushes, because we want to use a single URL, so we can't redirect anything.
- For now, secondaries are only used to improve Git pulls
- Figure out how to properly handle CSRF protection
- Open follow up issues to:
- Somehow show both primary and secondary stuff in
Admin Area > Geo
- Show other secondary stuff like
Admin Area > Background Jobs
, etc... - Serve other local stuff from secondaries: Uploads, Job artifacts, etc
- Somehow show both primary and secondary stuff in
Details
- This should be controlled with an ApplicationSetting. Either opt-in or opt-out.
- I can imagine a use-case for a setting per GeoNode, but it increases cognitive complexity for users and devs, and we could transition to that later if we have to, if customers really want it.
- I prefer opt-out setting
[ ] Disable proxying UI and API requests to the primary
defaulted to checked for existing installations. This implies that opt-out is the exceptional case. I would eventually remove the setting on a major version bump if all is going well, so we don't have to support large differences in use-cases.
- Proxying seems to have greater potential in the long-term. And it can be done iteratively:
- Proxy everything except Git pulls. Feature flagged.
- Exclude OAuth and Admin Area from proxying (since secondary Admin Area is different and necessary at the moment)
- Add setting
[ ] Disable proxying UI and API requests to the primary
defaulted to checked for existing installations. - Remove feature flag (MVP done)
- New feature: Accelerate Rails app
assets
- New feature: Accelerate locally stored and proxied remote stored Uploads
- New feature: Accelerate locally stored and proxied remote stored Job artifacts
- New feature: Accelerate locally stored and proxied remote stored LFS objects
- New feature: Accelerate anything else immutable
- New feature: Unified Admin Area? View and manage any necessary secondary Admin Area things in the primary Admin Area. This may be big, but it enables the next thing.
- New feature: One URL to rule them all. Direct access to the primary is no longer a requirement. How? A unique, user-accessible, primary address is required to support OAuth. But since you no longer need to access the secondary Admin Area, we can remove OAuth and secondary Admin Area direct-access proxy exclusions.
- Regarding the proxy solution, we could use a POC to answer:
- How much effort would it take to release an MVP?
- How would CSRF be handled? (I think this might have only been an issue when proxying only write actions !10309 (closed))
- How is the user experience?
- How is the admin experience?
- How is the sysadmin experience?
- If the above does not indicate a clear win, then we could use a redirect solution POC to answer similar questions for that approach.
- If it looks like we can achieve a proxying MVP with reasonable effort: then ATM I would go straight to this route over redirecting.
- If redirect first, then proxy later: I haven't thought through the upgrade path
You could give out only a single URL, but I hesitate to say you don't need the primary to be accessible at a unique URL. It is a great fallback to have, and we can't redirect anything to the primary without it.