We can look forever at different cloud backends, hypervisors, vm containers and provisioning (OpenVZ, Docker, OpenStack, Vagrant, minijail0, firejail, etc.). But at some point we should stop looking for alternatives and go with something that works and fills our requirements.

We can probably skip looking at JClouds as the OpenStack Infra team considered that already, but found it didn't work well for this purpose. See also T47499#960316.

From irc://chat.freenode.net/#openstack-infra

mordred wrote:

you will find that the jenkins jclouds plugin is almost certainly not good enough
I say this with love as the person who funded most of the work to write it
we spent almost a year trying to go down that path before we wrote nodepool
the main issue we ran in to is that the logic of what we're wanting to do is here actualy a bit counter to the internal data model in jenkins
the jenkins scheduler looks at the resources it has available and makes decisions on what run and what to queue based on that
so then in the other cloud launchers and the jclouds launcher, there's essentially a virtual node provider which is "always" available for scheduling, but then the interaction with either node creation or pulling something from a pool happens at the time of job request
by keeping it as an external pool that uses the jenkins API and subscribes to jenkins notification events, nothing strange has to be done from the jenkins perspective wrt scheduling of work
if there is a slave attached with an ubuntu label and a job that wants to run on it, jenkins does the right thing. if, for whatever reason, there is not, jenkins also does the right thing

Krinkle wrote:

And I suppose creation of instances to be hot standys in a pool, wouldn't be possible in jclouds model?

mordred wrote:

well, it could be - but you'd be doing it all essentially inside of a daemon thread inside of jenkins - so the model would be similar other than you'd be colocated in the same process space