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(a)redhat.com
RHEV-CI Team