vtctld: flag to proxy vttablet URLs #6058
Conversation
Signed-off-by: Sugu Sougoumarane <ssougou@gmail.com>
Signed-off-by: Sugu Sougoumarane <ssougou@gmail.com>
|
I tested it manually. But was out of my element on an automated test. If someone wants to write a test, I'd be very happy to accept the work. |
|
Should this also allow proxying vtgate endpoints? In the long run that would set up the VTCtld as a single destination for HTTP apis which feels good. |
VTGates haven't become discoverable yet. I think there's a feature request for it. But once they do, we'd naturally have to extend vtctld for them. |
| proxyMu.Lock() | ||
| defer proxyMu.Unlock() | ||
| if _, ok := remotes[tabletID]; ok { | ||
| return |
There was a problem hiding this comment.
Does this mean the proxy will stop working for a given tablet after its address changes?
| } | ||
| return nil | ||
| } | ||
| http.Handle(prefixPath, rp) |
There was a problem hiding this comment.
It would be more natural to respond to tablets coming/going and changing addresses if there were only one handler, which looks at a cached lookup table of tablet aliases to addresses.
There was a problem hiding this comment.
It would be more natural to respond to tablets coming/going and changing addresses if there were only one handler, which looks at a cached lookup table of tablet aliases to addresses.
This is what I started out with. The problem with the unified approach is that there is no easy way to associate a response to a request, which is needed for rewriting URLs to match the tablet id. I looked at making the vttablets send an extra header identifying the tablet id. But the one-proxy-per-tablet felt much simpler.
What I'll instead do is replace the per-tablet proxy every time. I looked at the code. It's just metdata (no goroutines etc). So, it should be fine.
There was a problem hiding this comment.
Oh I see. Couldn't you still have a single handler though? If reverse proxy objects are cheap to make, you can just make a new one for each request you handle and use it once. Then you don't have handlers slowly leaking in cases when tablet IDs go away.
There was a problem hiding this comment.
Currently, the page that renders the tablets is the one that causes the map entry to be created.
Thinking about it again, there's no real need for that page to be controlling the redirects. We could directly GetTablet at the time of request, create the redirect and forward it. Let me update the other PR to reflect this.
This is a long awaited change. Adding a
-proxy_tabletsflag to vtctld which will make it act as a reverse proxy for all its vttablets.This should ease a lot of pain from the kubernetes users.