Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-40847

JNLP slave pod gets created even when a different slave is configured

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Critical Critical
    • kubernetes-plugin
    • None
    • kubernetes 1.51, coreos, kubernetes plugin 0.10

      plugin 0.10... I have a kubernetes pod template configured with a different slave image than the default JNLP slave template. For some reason when I look at pods for my slave nodes I now see both the jenkinsci/jnlp-slave:alpine container and my intended container:

      jenkins-docker-dood-slave
      Image:
      pswenson/jenkins-docker-dood-slave:2.0

      This causes big problems as the jobs almost always go to the JNLP slave instead of the jenkins-docker-dood-slave and this causes a job failure (my custom slave image runs docker commands and uses a shared docker socket)

      The old 0.8 version didn't have this problem, however that version doesn't appear to work with kube 1.51.

      I'm going to look at the source code of the plugin and see if I can figure out what's going on. Any suggestions would be greatly appreciated.

          [JENKINS-40847] JNLP slave pod gets created even when a different slave is configured

          Lars Lawoko added a comment -

          We had the same problem;
          either name your container 'jnlp' as a hack,
          or do a container step

          container('<name>') {
//code 
}

          relevent code:
          https://github.com/jenkinsci/kubernetes-plugin/blob/master/src/main/java/org/csanchez/jenkins/plugins/kubernetes/KubernetesCloud.java

          if (!containers.containsKey(JNLP_NAME)) {
            ContainerTemplate containerTemplate = new ContainerTemplate(DEFAULT_JNLP_IMAGE);
            containerTemplate.setName(JNLP_NAME);
            containerTemplate.setArgs(DEFAULT_JNLP_ARGUMENTS);
            containers.put(JNLP_NAME, createContainer(slave, containerTemplate, template.getEnvVars(), volumeMounts.values()));
        }

          Lars Lawoko added a comment - We had the same problem; either name your container 'jnlp' as a hack, or do a container step container( '<name>' ) { //code } relevent code: https://github.com/jenkinsci/kubernetes-plugin/blob/master/src/main/java/org/csanchez/jenkins/plugins/kubernetes/KubernetesCloud.java if (!containers.containsKey(JNLP_NAME)) { ContainerTemplate containerTemplate = new ContainerTemplate(DEFAULT_JNLP_IMAGE); containerTemplate.setName(JNLP_NAME); containerTemplate.setArgs(DEFAULT_JNLP_ARGUMENTS); containers.put(JNLP_NAME, createContainer(slave, containerTemplate, template.getEnvVars(), volumeMounts.values())); }

          Lars Lawoko added a comment - - edited

          Note that We have had a problem with WithEnv block inside a container block, issue JENKINS-40647

          Lars Lawoko added a comment - - edited Note that We have had a problem with WithEnv block inside a container block, issue JENKINS-40647

          Vincent Robert added a comment -

          Same problem.

          The 0.9 version doesn't have the problem.

          Vincent Robert added a comment - Same problem. The 0.9 version doesn't have the problem.

          phil swenson added a comment -

          I successfully worked around the issue by putting "jnlp" in the container name for the kubernetes container config as suggested by Lars. Thanks!

          phil swenson added a comment - I successfully worked around the issue by putting "jnlp" in the container name for the kubernetes container config as suggested by Lars. Thanks!

          Carlos Sanchez added a comment -

          philswenson wdym? you run one slave and call commands in another container or just create your custom slave image with ruby

          Carlos Sanchez added a comment - philswenson wdym? you run one slave and call commands in another container or just create your custom slave image with ruby

          phil swenson added a comment -

          i didn't follow your comment, but my comment was incorrect so I deleted it. The work-around for the bug is naming the container 'jnlp' to prevent the k8s plugin from creating a jnlp container, so you can have as many slave types as you like.

          phil swenson added a comment - i didn't follow your comment, but my comment was incorrect so I deleted it. The work-around for the bug is naming the container 'jnlp' to prevent the k8s plugin from creating a jnlp container, so you can have as many slave types as you like.

          Jae Gangemi added a comment -

          JENKINS-41040 is related

          Jae Gangemi added a comment - JENKINS-41040 is related

          Carlos Sanchez added a comment -

          This has been clarified in README and CHANGELOG in https://github.com/jenkinsci/kubernetes-plugin/commit/8849676cf1c334506361244917ec9af02bc516f4 and https://github.com/jenkinsci/kubernetes-plugin/commit/a9bb356e021a89fd174472217aa112ea37c0b308

          Carlos Sanchez added a comment - This has been clarified in README and CHANGELOG in https://github.com/jenkinsci/kubernetes-plugin/commit/8849676cf1c334506361244917ec9af02bc516f4 and https://github.com/jenkinsci/kubernetes-plugin/commit/a9bb356e021a89fd174472217aa112ea37c0b308

          Carlos Sanchez added a comment -

          Documentation and changelog has been edited to clarify the container name requirement.

          if you have defined a JNLP container in your Pod definition, you need to remove it or rename it to `jnlp`, otherwise a new container called `jnlp` will be created.

          Carlos Sanchez added a comment - Documentation and changelog has been edited to clarify the container name requirement. if you have defined a JNLP container in your Pod definition, you need to remove it or rename it to `jnlp`, otherwise a new container called `jnlp` will be created.

          Sergey Kulanov added a comment -

          Folks, probably JENKINS-41137 is a duplication of JENKINS-41040 (so, please feel free to close as dup.), but I've made a little investigation and the question is (duplicating here my last comment):

          Ok, it seems that checkouting happens inside jnlp container. Is it expected behavior or I missed (mis-configured) something

1. If yes, then jnlp container requires openssh-client package (at least the default one, which is jenkinsci/jnlp-slave:alpine)
2. It'll be nice to have Dockerfile for jenkinsci/jnlp-slave:alpine container in https://github.com/jenkinsci/docker-jnlp-slave as well

          Sergey Kulanov added a comment - Folks, probably JENKINS-41137 is a duplication of JENKINS-41040 (so, please feel free to close as dup.), but I've made a little investigation and the question is (duplicating here my last comment): Ok, it seems that checkouting happens inside jnlp container. Is it expected behavior or I missed (mis-configured) something 1. If yes, then jnlp container requires openssh-client package (at least the default one, which is jenkinsci/jnlp-slave:alpine) 2. It'll be nice to have Dockerfile for jenkinsci/jnlp-slave:alpine container in https: //github.com/jenkinsci/docker-jnlp-slave as well

            csanchez Carlos Sanchez
            philswenson phil swenson
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: