Currently Remoting agents always require Jenkins master to have a Tcp Agent Listener endpoint. It complicates usage of Remoting with CloudAPI-provided agents together with Jenkinsfile Runner which does not have a fixed Web UI port.
I propose to add new options to Remoting so that it can connect without polling metadata from the master
We're running Jenkinsfile Runner on a Kubernetes cluster and use the Kubernetes plugin to dynamically spawn new agents. JNLP connections to the master failed and as a quick workaround, we've opened the HTTP port of the Jenkinsfile Runner. Changing Remoting for this is of course the cleaner solution.
Oleg Nenashev Any idea when you will continue working on this topic?