Do you suggest that we should use the original tracking url directly instead of proxy url on the web UI?
Not sure if it's always OK to use the raw history tracking URL, as there might be some setups where the client can reach the RM but can't reach the history tracking URL directly. However I think it's OK to always have the RM advertise the original proxy tracking URL (i.e.: http://<rmaddr>/proxy/<appid>) to clients through its UI. The AM can redefine what that proxy redirects to, but the RM should never tack on paths to that proxy URI when advertising it. In other words, clients visiting http://<rmaddr>/proxy<appid> will always reach the UI (either AM or history), and if the AM and history have properly mirrored UIs then it should be seamless to transition between the two when the AM unregisters and redefines the tracking URL to point to the history server.
seamless view between the AM UI and history UI is not possible nowadays.
Correct, but that's MapReduce's fault and not YARN's. If the RM handles the proxy properly then it should be possible for an app framework to implement a properly mirrored UI between the AM and the history server.
In general, seamless view will still be difficult with the aforementioned solution between two tracking URLs. For example, tracking URL is http://t1:p1/a/b first, and I'm visiting the path at http://t1:p1/a/b/x/y/z. When the tracking URL becomes http://t2:p2/c/d/e, I refresh the package and am redirected http://t2:p2/c/d/e/a/b/x/y/z. Without mapping between original tracking url and proxy url, we don't know /a/b is part of tracking url base, and it shouldn't be carried on.
Not sure I'm following the example because there's no proxy URLs in it. The client should always be using the proxy URL for this discussion. If I follow the example correctly, the original tracking URL is http://t1:p1/a/b, and the proxy URL is rooted there (i.e.: proxy/<appid> -> t1:p1/a/b). So I'm visiting proxy/<appid>/x/y/z and then the AM unregisters with a new tracking URL of t2:p2/c/d/e. Then the proxy servlet should redirect that same proxy/<appid>/x/y/z request to t2:p2/c/d/e/x/y/z which seems correct to me. It's just taking the path underneath the proxy address (i.e.: everything after proxy/<appid>) and tacking it on the specified tracking URL. The same subpath is seen by both the AM and history URIs, assuming a/b is the root of the AM UI and c/d/e is the root of the history UI (for that app). So it seems this works as I would expect. Am I missing something?
I have updated the generateProxyUriWithScheme() in the latest patch.
Thanks for updating the patch, Devaraj. I think it looks good, although it would be nice to have some regression tests to verify that if the app changes the tracking URL that the proxy URL doesn't update like it used to.