[kubernetes-plugin | casc ] Different behaviour between declarative and casc configuration ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[kubernetes-plugin | casc ] Different behaviour between declarative and casc configuration ?

Akram Ben Aissi
Hi Jenkins-Dev,

I am trying to port a configuration of the kubernetes-plugin between servers and I was facing an issue while trying to use the casc to do it.

If I use declarative (or yaml) in Jenkinsfile to declare a podTemplate()  , I can safely omit the containerTemplate named `jnlp` and it seems that this one is automatically created and it uses a default image that does the job.

If I use casc, and omit it on purposes, it seems to have a different behaviour, and actually in runtime, I face a NullPointerException. 


```
2020-09-08 15:02:39.434+0000 [id=41] WARNING o.c.j.p.k.KubernetesLauncher#launch: Error in provisioning; agent=KubernetesSlave name: maven-jw1z8, template=PodTemplate{, name='maven', slaveConnectTimeout=30, label='maven', serviceAccount='jenkins', nodeUsageMode=EXCLUSIVE, workspaceVolume=EmptyDirWorkspaceVolume [memory=false], containers=[ContainerTemplate{name='maven', image='image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-maven:latest', alwaysPullImage=true, workingDir='/tmp'}]}
java.lang.NullPointerException
at org.csanchez.jenkins.plugins.kubernetes.PodUtils.cancelQueueItemFor(PodUtils.java:76)
at org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher.launch(KubernetesLauncher.java:138)
at hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:297)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
```

If I forcibely create the `jnlp` container using my agent image, it seems to work. But, I want to get rid of the jnlp container and use the default one actually. Any idea ?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/93d89e27-b3d4-4e20-90d1-9adff9bace59n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: [kubernetes-plugin | casc ] Different behaviour between declarative and casc configuration ?

vlatombe
(this is rather a question for Jenkins Users)

This smells like a bug. Please open a jira issue with a reproducer.

Vincent


Le mer. 9 sept. 2020 à 10:32, [hidden email] <[hidden email]> a écrit :
Hi Jenkins-Dev,

I am trying to port a configuration of the kubernetes-plugin between servers and I was facing an issue while trying to use the casc to do it.

If I use declarative (or yaml) in Jenkinsfile to declare a podTemplate()  , I can safely omit the containerTemplate named `jnlp` and it seems that this one is automatically created and it uses a default image that does the job.

If I use casc, and omit it on purposes, it seems to have a different behaviour, and actually in runtime, I face a NullPointerException. 


```
2020-09-08 15:02:39.434+0000 [id=41] WARNING o.c.j.p.k.KubernetesLauncher#launch: Error in provisioning; agent=KubernetesSlave name: maven-jw1z8, template=PodTemplate{, name='maven', slaveConnectTimeout=30, label='maven', serviceAccount='jenkins', nodeUsageMode=EXCLUSIVE, workspaceVolume=EmptyDirWorkspaceVolume [memory=false], containers=[ContainerTemplate{name='maven', image='image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-maven:latest', alwaysPullImage=true, workingDir='/tmp'}]}
java.lang.NullPointerException
at org.csanchez.jenkins.plugins.kubernetes.PodUtils.cancelQueueItemFor(PodUtils.java:76)
at org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher.launch(KubernetesLauncher.java:138)
at hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:297)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
```

If I forcibely create the `jnlp` container using my agent image, it seems to work. But, I want to get rid of the jnlp container and use the default one actually. Any idea ?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/93d89e27-b3d4-4e20-90d1-9adff9bace59n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-zGCi%3DF1owG1XRLBERS%3Dbvip%3D3EKXEBHmwiC6KgLDwDRmWFQ%40mail.gmail.com.