Hello,

The OpenStack cloud plugin (2.17) currently fails to wait for JNLP connections when the node is provisioned from a Jenkins 2.0 style pipeline project.

This can result in the OpenStack plugin continually provisioning JNLP nodes until a JNLP agent establishes a connection to master and reduces the `excessWorkload` for the node/label from 1 to 0, the OpenStack tenant runs out of compute resources, or the global instance cap is reached -whichever comes first.

A simple pipeline can exhibit the problem:

stage('Provisioning') {
	parallel(
		linux: {
			node('ssh') {
				sh: 'echo "hello"'
			}
		},
		windows: {
			node('long-startup-jnlp') {
				bat: 'echo "hello"'
			}
		}
	)
}

From what I can tell, the JNLP node currently reports isReady immediately --even before the provisioned JNLP node has has even had a chance to establish its connection with the Jenkins master. This differs from the SSH node, which probes the connection to determine what isReady should return.

Admittedly, the problem is likely exacerbated by my OpenStack environment --my JNLP node takes nearly twice as long as the SSH node to complete Cloud-Init phase and phone home. To work around this, I can limit the capacity from the default of 10 to a smaller number, but that doesn't really resolve the underlying issue in a satisfying way.

It's also worth noting that I do not observe this same phenomenon when I manually provision a node via the `Provision via OpenStack Cloud Plugin` drop down on the executor's page. Here, as expected, only one node is ever provisioned. I assume this step must reduce the `excessWorkload` to 0, whereas the JNLP provisioned from my pipeline doesn't.

I'm working on a proposed patch, but I need to walk it through OSS compliance first. I'll open a pull request if/when I can get it approved.

Thanks for all your hard work,
Ryan