Skip to content

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 add Admin 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

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:
    1. Proxy everything except Git pulls. Feature flagged.
    2. Exclude OAuth and Admin Area from proxying (since secondary Admin Area is different and necessary at the moment)
    3. Add setting [ ] Disable proxying UI and API requests to the primary defaulted to checked for existing installations.
    4. Remove feature flag (MVP done)
    5. New feature: Accelerate Rails app assets
    6. New feature: Accelerate locally stored and proxied remote stored Uploads
    7. New feature: Accelerate locally stored and proxied remote stored Job artifacts
    8. New feature: Accelerate locally stored and proxied remote stored LFS objects
    9. New feature: Accelerate anything else immutable
    10. 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.
    11. 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.

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Links / references

Edited by Fabian Zimmer