So essentially no, this is what I said I wanted to avoid :/
I was under the impression you are thinking about a wrapper job you need to wrap around every job. This is a single, out of band, job. So it may not be that bad. You seem to imply that slaves managed by the Swarm plugin are not 'normal' ssh-based slaves, so there might be something there we can exploit (For example, perhaps the swarm client JAR can be made to exit once the slave is brought offline, so we can wrap it in a script that will shut the slave down when it does). I will look deeper into this in my POC.
We have a small range right now for non-jenkins vms, but it's easy (maybe not fast, but easy) to get the slaves to free another range. But we would have to do so anyhow unless we use internal ips or request a new range.
So essentially we need to do the mapping work I mentioned in my original mail. Or I'm not understanding what you mean.
Afaik the swarm plugin is an extension of the jnlp slave connection method, and does not allow to change the connection method to ssh, it uses it's own (or so it seems from the docs, maybe that changed) that is to connect to the master from the slave.
I got a different impression from the docs, we will have to just try it and see I guess. -- Barak Korren bkorren@redhat.com RHEV-CI Team