Set instance cap by machine, not just by image

[stormbeta]

It doesn't seem like there's a way to enforce an instance cap at the machine (docker host) level rather than image level. This poses a problem when we have several different images, but only want one or two instances to run on a box at a time (to avoid overloading the box).

[thomassuckow]

+1

[magnayn]

Yeah, that's probably a good idea. I'm not sure the calculation is working correctly currently, there seems to be some race condition in there.

[rbywater]

I can't seem to actually get it to start two same image jobs to run. Say I've got a docker image with "java" as a label, if I start the first job that uses the java label it starts up the docker container and starts work. If I then start a second (different) job that uses the java label, it sits there saying its waiting for a free executor on the slave node created by the first job.

[jocelyndrw]

@rbywater I don't have any issue getting it to start more than one job with the same image, quite the opposite actually. Sometime it takes some time to launch more than 1 container (~ 1 or 2 minutes), maybe your jobs are too fast and it does not have the time to start a new executor ?

@magnayn Yes the current code is not really working and I often find myself having a lot more containers running on one host compared to what I defined in the image instance cap.

I'me having quite a hard time understanding how Jenkins is using the Cloud.provision() method as it manages to call the callback in

new NodeProvisioner.PlannedNode(t.getDisplayName(),
    Computer.threadPoolForRemoting.submit(new Callable<Node>() {
        [...]
    })

multiple times, without checking the result of addProvisionedSlave()
Anyway, I must be missing something ;)

Edit: I figured it out reading Jenkins cloud documentation and the EC2 plugin code. The PR #34 fixes the race condition and add an instance cap per machine.

[rbywater]

Strange - will have to try and debug why it's occurring on my instance. Out
of interest, what version of Jenkins are you running as I'm running the
latest non-lts one.

[jocelyndrw]

I'm running ver. 1.566, will try with the latest (1.568) tomorrow if you want.

[fraz3alpha]

I'm really keen to get hold of this fix/enhancement. Is it expected to be rolled into a release shortly - or should I try to manually build a package to install?

[magnayn]

I've merged it - soonest I can get a release out is probably tonight (I'm firewalled from :8081).

One note - I suspect the template cap might be unreliable. It's got nothing to do with this patch, but the code I wrote here:

Collection<Container> matching = Collections2.filter(containers, new Predicate<Container>() {
              public boolean apply(@Nullable Container container) {
                  ContainerInspectResponse cis = dockerClient.container(container.getId()).inspect();
                  return (cis.getImage().equalsIgnoreCase(ir.getId()));
              }
          });

Isn't quite right; it seems that the image returned by docker is arbitary if it has multiple tags. I.E: answering the question 'is this container based on this image' isn't as simple as that. If you don't have >1 tag per image, you'll probably be ok.

[jocelyndrw]

@rbywater It (multiple jobs with the same image) seems to be working fine with the last jenkins version (1.568). However I'm currently running Docker 0.11 as the 1.0 isn't available on CentOS yet, don't know if it makes a difference.

[magnayn]

@dreewoo you'll probably need 1.0 with plugin > 0.6, as the JSON API changed quite a bit.

[magnayn]

MErged