ReleaseEngineering/Applications/Proxxy: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 10: Line 10:


Clients request files explicitly from the proxxy rather than relying on transparent network proxies, or HTTP_CACHE environment settings. Since the proxxy instances can be handling multiple endpoints, we prepend the hostname of the original url to the proxxy url. e.g. to fetch http://ftp.mozilla.org/foo/bar, the client would first check http://ftp.mozilla.org.proxxy.srv.releng.use1.mozilla.com. Much of this logic is handled by mozharness' proxxy mixin.
Clients request files explicitly from the proxxy rather than relying on transparent network proxies, or HTTP_CACHE environment settings. Since the proxxy instances can be handling multiple endpoints, we prepend the hostname of the original url to the proxxy url. e.g. to fetch http://ftp.mozilla.org/foo/bar, the client would first check http://ftp.mozilla.org.proxxy.srv.releng.use1.mozilla.com. Much of this logic is handled by mozharness' proxxy mixin.
The reasons we chose to have such a setup, rather than a traditional proxy setup, include:
* (main reason): explicit is better than implicit - from the url we can see which cache we are hitting
* transparent proxies are hard to debug or see what's going on
* using http_proxy or env vars may not be obvious in logging
* with traditional proxies it can be difficult to switch to use different backends, or offer multiple proxy instances


If any authentication required, e.g. for pvtbuilds, then proxxy has those credentials baked into the AMI. Test clients on the local network can then request those files from proxxy without authentication.
If any authentication required, e.g. for pvtbuilds, then proxxy has those credentials baked into the AMI. Test clients on the local network can then request those files from proxxy without authentication.
Confirmed users
142

edits

Navigation menu