Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instruct PUB to rewrite paths #122

Open
iszulcdeepsense opened this issue Jan 12, 2023 · 2 comments
Open

Instruct PUB to rewrite paths #122

iszulcdeepsense opened this issue Jan 12, 2023 · 2 comments
Labels
wontfix This will not be worked on

Comments

@iszulcdeepsense
Copy link
Collaborator

iszulcdeepsense commented Jan 12, 2023

Some third-party applications like HUGO or Sphinx, running as a Fatman, expect requests to arrive at the root path (without any prefix). However, PUB component is serving requests at prefixed path (/pub/fatman/{name}/{version}/{subpath}) and passes them further, keeping the original path, which is unknown to the application.
To make it work, Fatman usually is composed of 2 containers: proxy and an actual application. The "proxy" container is responsible for trimming down the URL path from /pub/fatman/{name}/{version}/{subpath} to /{subpath}.

Here's an idea to move that responsibility to PUB and to instruct PUB whether the paths should be rewritten or not, before passing it further to a Fatman.
A new field rewrite_paths: bool should be kept in a database next to a Fatman object to be fetched by PUB beforehand.

@iszulcdeepsense
Copy link
Collaborator Author

iszulcdeepsense commented Jan 12, 2023

On the other hand, keep in mind that when deploying third-party apps, they usually don't serve /live and /ready endpoints, but Racetrack expects them to regularly check the condition of a Fatman by running liveness probes.

Either way, an additional "proxy" container would be still necessary in this case to fulfill the liveness probes, resulting in the "RUNNING" fatman's status. So this feature wouldn't help much.

@JosefAssadERST
Copy link
Member

It's interesting that RT currently requires /live and /ready, because it suggests that the current design assumes K8sish/dockerish infrastructure targets. If we implement a VMWare or even something like a fly.io or Heroku infrastructure plugin, such endpoints can of course be constructed but are not "native" there.

@iszulcdeepsense iszulcdeepsense added the wontfix This will not be worked on label Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants