You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the taskcluster proxy port must be specified in the generic worker configuration. As far as I can tell, there's nothing external to generic worker that needs to know this port, which means it could potentially probe for a bindable port itself instead. This would help avoid misconfigurations like we found in https://bugzilla.mozilla.org/show_bug.cgi?id=1889647.
The text was updated successfully, but these errors were encountered:
This is a nice idea. One thing to be careful of is that some tasks historically used http://taskcluster as the taskcluster proxy base URL. On workers, taskcluster name mapped to 127.0.0.1, typically via an entry in /etc/hosts or equivalent file on Windows. For backward compatibility, TASKCLUSTER_PROXY_URL is currently typically http://localhost:80 so that any tasks still using http://taskcluster for taskcluster proxy base URL still work. If we change default from being port 80, to being a non-static bindable port, anything using http://taskcluster explicitly will break. This is probably ok, most tasks by now should be using TASKCLUSTER_PROXY_URL env variable. But we should probably release this as a breaking change.
@jcristau also pointed out, workers could steal ports that tasks wanted to use, but perhaps that is acceptable fallout and can be worked around. I assume the request here is only to change default behavior when no port is specified. Presumably, the config property can be retained, so that an explicit value can be set to overwrite the default value.
At the moment, the taskcluster proxy port must be specified in the generic worker configuration. As far as I can tell, there's nothing external to generic worker that needs to know this port, which means it could potentially probe for a bindable port itself instead. This would help avoid misconfigurations like we found in https://bugzilla.mozilla.org/show_bug.cgi?id=1889647.
The text was updated successfully, but these errors were encountered: