[JIRA] (JENKINS-62195) ec2-1.50.2 doesn't work with SSH <7.5
Title: Message Title John Jeffers commented on JENKINS-62195 Re: ec2-1.50.2 doesn't work with SSH <7.5 Thank you. I was lucky that I had a backup to recover from. Would have been very bad otherwise. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.206127.1588831961000.24257.1589126760410%40Atlassian.JIRA.
[JIRA] (JENKINS-62195) ec2-1.50.2 doesn't work with SSH <7.5
Title: Message Title John Jeffers commented on JENKINS-62195 Re: ec2-1.50.2 doesn't work with SSH <7.5 Confirmed, happening here as well. We are using the latest LTS image, jenkins/jenkins:2.222.3 root@jenkins-master-fb7584fbb-s6nnl:/# ssh -V OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019 Also worth noting that when I attempted to downgrade the plugin, it did not downgrade properly and instead seemed to uninstall the plugin, taking all of its config with it. I had to manually downgrade and restore config.xml from a backup. I believe this has something to do with the ec2.xml file it drops into $JENKINS_HOME, because I could not get 1.50.1 working again until I removed that file. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.206127.1588831961000.23500.1588908360221%40Atlassian.JIRA.
[JIRA] (JENKINS-62043) EC2 nodes broken
Title: Message Title John Jeffers commented on JENKINS-62043 Re: EC2 nodes broken I upgraded the plugin when I had no EC2 instances registered in Jenkins, and it seems to be fine now. So it does seem to be a problem that occurs if the plugin is upgraded when there are registered EC2 build agents. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.205934.1587719449000.18738.1588048980328%40Atlassian.JIRA.
[JIRA] (JENKINS-62043) EC2 nodes broken
Title: Message Title John Jeffers commented on JENKINS-62043 Re: EC2 nodes broken I can confirm that this behavior is also stopping my kubernetes-based jobs from starting, not only EC2 jobs. Getting a ton of NPE's in the logs. I had to roll back to 1.49.1 to get anything to work. Log samples: jenkins-master-fb7584fbb-cf8lb jenkins-master 2020-04-27 07:14:23.104+ [id=230] WARNING h.ExpressionFactory2$JexlExpression#evaluate: Caught exception evaluating: !c.acceptingTasks in /. Reason: java.lang.reflect.InvocationTargetException jenkins-master-fb7584fbb-cf8lb jenkins-master java.lang.NullPointerException jenkins-master-fb7584fbb-cf8lb jenkins-master at hudson.plugins.ec2.EC2AbstractSlave.isAcceptingTasks(EC2AbstractSlave.java:471) jenkins-master-fb7584fbb-cf8lb jenkins-master at hudson.model.Computer.isAcceptingTasks(Computer.java:1632) jenkins-master-fb7584fbb-cf8lb jenkins-master at hudson.slaves.SlaveComputer.isAcceptingTasks(SlaveComputer.java:178) jenkins-master-fb7584fbb-cf8lb jenkins-master Caused: java.lang.reflect.InvocationTargetException jenkins-master-fb7584fbb-cf8lb jenkins-master at sun.reflect.GeneratedMethodAccessor330.invoke(Unknown Source) jenkins-master-fb7584fbb-cf8lb jenkins-master at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) jenkins-master-fb7584fbb-cf8lb jenkins-master at java.lang.reflect.Method.invoke(Method.java:498) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.parser.ASTNotNode.value(ASTNotNode.java:56) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.parser.ASTExpression.value(ASTExpression.java:54) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.parser.ASTExpressionExpression.value(ASTExpressionExpression.java:56) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) jenkins-master-fb7584fbb-cf8lb jenkins-master at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateAsBoolean(ExpressionSupport.java:71) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:97) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:81) jenkins-master-fb7584fbb-cf8lb jenkins-master at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:124) jenkins-master-fb7584fbb-cf8lb jenkins-master at
[JIRA] (JENKINS-37858) Group based LDAP authentication does not work
Title: Message Title John Jeffers commented on JENKINS-37858 Re: Group based LDAP authentication does not work Any chance we can get someone to look into this? I have the same problem as others here, also using Jumpcloud. The only way I can get LDAP groups to work is if I give the user account "Enable as LDAP Bind DN" permissions. Without that, group memberships are not honored, and the logged in user does not get the permissions assigned to the group. Does anyone using other LDAP providers have this problem, or is this unique to Jumpcloud? Not really sure who I should be asking to fix this problem. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.173992.1472656539000.15450.1577219820381%40Atlassian.JIRA.
[JIRA] (JENKINS-60255) EC2 plugin creating extra unused EC2 instances
Title: Message Title John Jeffers created an issue Jenkins / JENKINS-60255 EC2 plugin creating extra unused EC2 instances Issue Type: Bug Assignee: FABRIZIO MANFREDI Components: ec2-plugin Created: 2019-11-23 20:22 Environment: Jenkins version 2.190.3, running in k8s using official docker image ec2 plugin version 1.46.1 Priority: Critical Reporter: John Jeffers The EC2 plugin creates extra EC2 instances that it does not end up using. For instance, right now there are 5 EC2 instances launched by the plugin, but only 2 of those are registered in Jenkins as build executors. If I terminate the unused instances, the plugin launches new ones. Is there any way to fix this? Add Comment
[JIRA] (JENKINS-54170) Kubernetes agent does not connect on first several attempts
Title: Message Title John Jeffers closed an issue as Fixed This was a problem with the JNLP service in kubernetes. As a node port service, it was doing round-robin through the available IPs, but would only connect if it happened to get the IP of the worker node running Jenkins. Any other IP would cause it to time out and retry. The problem would get worse the more worker nodes were present in the cluster. I solved the problem by changing the service to a headless clusterIP, which is possible only because EKS gives pods VPC-native IPs. I'm not sure how I would solve this problem in a Kubernetes cluster using some other CNI that gives the pods addresses outside of the VPC range. Jenkins / JENKINS-54170 Kubernetes agent does not connect on first several attempts Change By: John Jeffers Status: Open Closed Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the
[JIRA] (JENKINS-54170) Kubernetes agent does not connect on first several attempts
Title: Message Title
John Jeffers updated an issue
Jenkins / JENKINS-54170
Kubernetes agent does not connect on first several attempts
Change By:
John Jeffers
Comment:
I could never find a network issue, but I have noticed that behavior has changed with the latest version of the plugin (specifically, version 1.14.6). Now, instead of a constant stream of failed connection messages, it instead keep spinning up pods until one of them finally accepts the job. In one recent run, it created 9 of the same pod, finally ran the job on one, then eventually terminated all of the pods it didn't need.{code:java}Mar 02, 2019 4:13:04 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Excess workload after pending Kubernetes agents: 1Mar 02, 2019 4:13:04 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Template for label jfrog-cli-go: Kubernetes Pod TemplateMar 02, 2019 4:13:04 AM okhttp3.internal.platform.Platform logINFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path?Mar 02, 2019 4:13:04 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl applyINFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0Mar 02, 2019 4:13:14 AM hudson.slaves.NodeProvisioner$2 runINFO: Kubernetes Pod Template provisioning successfully completed. We have now 2 computer(s)Mar 02, 2019 4:13:14 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launchINFO: Created Pod: jfrog-cli-go-rb88g-p7n9q in namespace jenkinsMar 02, 2019 4:13:14 AM okhttp3.internal.platform.Platform logINFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path?Mar 02, 2019 4:13:24 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Excess workload after pending Kubernetes agents: 1Mar 02, 2019 4:13:24 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Template for label jfrog-cli-go: Kubernetes Pod TemplateMar 02, 2019 4:13:24 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl applyINFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0Mar 02, 2019 4:13:34 AM hudson.slaves.NodeProvisioner$2 runINFO: Kubernetes Pod Template provisioning successfully completed. We have now 3 computer(s)Mar 02, 2019 4:13:34 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launchINFO: Created Pod: jfrog-cli-go-rb88g-96jd0 in namespace jenkinsMar 02, 2019 4:13:34 AM okhttp3.internal.platform.Platform logINFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path?Mar 02, 2019 4:13:44 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Excess workload after pending Kubernetes agents: 1Mar 02, 2019 4:13:44 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Template for label jfrog-cli-go: Kubernetes Pod TemplateMar 02, 2019 4:13:44 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl applyINFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0Mar 02, 2019 4:13:54 AM hudson.slaves.NodeProvisioner$2 runINFO: Kubernetes Pod Template provisioning successfully completed. We
[JIRA] (JENKINS-54170) Kubernetes agent does not connect on first several attempts
Title: Message Title
John Jeffers edited a comment on JENKINS-54170
Re: Kubernetes agent does not connect on first several attempts
I could never find a network issue, but I have noticed that behavior has changed with the latest version (s) of the plugin (specifically, version 1 . 14.6). Now, instead of a constant stream of failed connection messages, it instead keep spinning up pods until one of them finally accepts the job. In one recent run, it created 9 of the same pod, finally ran the job on one, then eventually terminated all of the pods it didn't need.{code:java}Mar 02, 2019 4:13:04 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Excess workload after pending Kubernetes agents: 1Mar 02, 2019 4:13:04 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Template for label jfrog-cli-go: Kubernetes Pod TemplateMar 02, 2019 4:13:04 AM okhttp3.internal.platform.Platform logINFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path?Mar 02, 2019 4:13:04 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl applyINFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0Mar 02, 2019 4:13:14 AM hudson.slaves.NodeProvisioner$2 runINFO: Kubernetes Pod Template provisioning successfully completed. We have now 2 computer(s)Mar 02, 2019 4:13:14 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launchINFO: Created Pod: jfrog-cli-go-rb88g-p7n9q in namespace jenkinsMar 02, 2019 4:13:14 AM okhttp3.internal.platform.Platform logINFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path?Mar 02, 2019 4:13:24 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Excess workload after pending Kubernetes agents: 1Mar 02, 2019 4:13:24 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Template for label jfrog-cli-go: Kubernetes Pod TemplateMar 02, 2019 4:13:24 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl applyINFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0Mar 02, 2019 4:13:34 AM hudson.slaves.NodeProvisioner$2 runINFO: Kubernetes Pod Template provisioning successfully completed. We have now 3 computer(s)Mar 02, 2019 4:13:34 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launchINFO: Created Pod: jfrog-cli-go-rb88g-96jd0 in namespace jenkinsMar 02, 2019 4:13:34 AM okhttp3.internal.platform.Platform logINFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path?Mar 02, 2019 4:13:44 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Excess workload after pending Kubernetes agents: 1Mar 02, 2019 4:13:44 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provisionINFO: Template for label jfrog-cli-go: Kubernetes Pod TemplateMar 02, 2019 4:13:44 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl applyINFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0Mar 02, 2019 4:13:54 AM hudson.slaves.NodeProvisioner$2 runINFO: Kubernetes Pod Template provisioning successfully completed. We have now 4 computer(s)Mar 02, 2019 4:13:54 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launchINFO: Created Pod: jfrog-cli-go-rb88g-j7qmx in namespace jenkinsMar 02, 2019 4:13:54 AM okhttp3.internal.platform.Platform logINFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path?Mar 02, 2019 4:14:00 AM com.squareup.okhttp.internal.Platform$JdkWithJettyBootPlatform getSelectedProtocolINFO: ALPN
[JIRA] (JENKINS-54170) Kubernetes agent does not connect on first several attempts
Title: Message Title
John Jeffers edited a comment on JENKINS-54170
Re: Kubernetes agent does not connect on first several attempts
I could never find a network issue, but I have noticed that behavior has changed with the latest version(s) of the plugin. Now, instead of a constant stream of failed connection messages, it instead keep spinning up pods until one of them finally accepts the job. In one recent run, it created 9 of the same pod, finally ran the job on one, then eventually terminated all of the pods it didn't need. { {``` code:java} Mar 02, 2019 4:13:04 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision }} {{ INFO: Excess workload after pending Kubernetes agents: 1 }} {{ Mar 02, 2019 4:13:04 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision }} {{ INFO: Template for label jfrog-cli-go: Kubernetes Pod Template }} {{ Mar 02, 2019 4:13:04 AM okhttp3.internal.platform.Platform log }} {{ INFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path? }} {{ Mar 02, 2019 4:13:04 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl apply }} {{ INFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0 }} {{ Mar 02, 2019 4:13:14 AM hudson.slaves.NodeProvisioner$2 run }} {{ INFO: Kubernetes Pod Template provisioning successfully completed. We have now 2 computer(s) }} {{ Mar 02, 2019 4:13:14 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch }} {{ INFO: Created Pod: jfrog-cli-go-rb88g-p7n9q in namespace jenkins }} {{ Mar 02, 2019 4:13:14 AM okhttp3.internal.platform.Platform log }} {{ INFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path? }} {{ Mar 02, 2019 4:13:24 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision }} {{ INFO: Excess workload after pending Kubernetes agents: 1 }} {{ Mar 02, 2019 4:13:24 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision }} {{ INFO: Template for label jfrog-cli-go: Kubernetes Pod Template }} {{ Mar 02, 2019 4:13:24 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl apply }} {{ INFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0 }} {{ Mar 02, 2019 4:13:34 AM hudson.slaves.NodeProvisioner$2 run }} {{ INFO: Kubernetes Pod Template provisioning successfully completed. We have now 3 computer(s) }} {{ Mar 02, 2019 4:13:34 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch }} {{ INFO: Created Pod: jfrog-cli-go-rb88g-96jd0 in namespace jenkins }} {{ Mar 02, 2019 4:13:34 AM okhttp3.internal.platform.Platform log }} {{ INFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path? }} {{ Mar 02, 2019 4:13:44 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision }} {{ INFO: Excess workload after pending Kubernetes agents: 1 }} {{ Mar 02, 2019 4:13:44 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision }} {{ INFO: Template for label jfrog-cli-go: Kubernetes Pod Template }} {{ Mar 02, 2019 4:13:44 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl apply }} {{ INFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0 }} {{ Mar 02, 2019 4:13:54 AM hudson.slaves.NodeProvisioner$2 run }} {{ INFO: Kubernetes Pod Template provisioning successfully completed. We have now 4 computer(s) }} {{ Mar 02, 2019 4:13:54 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch }} {{ INFO: Created Pod: jfrog-cli-go-rb88g-j7qmx in namespace jenkins }} {{ Mar 02,
[JIRA] (JENKINS-54170) Kubernetes agent does not connect on first several attempts
Title: Message Title John Jeffers commented on JENKINS-54170 Re: Kubernetes agent does not connect on first several attempts I could never find a network issue, but I have noticed that behavior has changed with the latest version(s) of the plugin. Now, instead of a constant stream of failed connection messages, it instead keep spinning up pods until one of them finally accepts the job. In one recent run, it created 9 of the same pod, finally ran the job on one, then eventually terminated all of the pods it didn't need. ```Mar 02, 2019 4:13:04 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision INFO: Excess workload after pending Kubernetes agents: 1 Mar 02, 2019 4:13:04 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision INFO: Template for label jfrog-cli-go: Kubernetes Pod Template Mar 02, 2019 4:13:04 AM okhttp3.internal.platform.Platform log INFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path? Mar 02, 2019 4:13:04 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl apply INFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0 Mar 02, 2019 4:13:14 AM hudson.slaves.NodeProvisioner$2 run INFO: Kubernetes Pod Template provisioning successfully completed. We have now 2 computer(s) Mar 02, 2019 4:13:14 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch INFO: Created Pod: jfrog-cli-go-rb88g-p7n9q in namespace jenkins Mar 02, 2019 4:13:14 AM okhttp3.internal.platform.Platform log INFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path? Mar 02, 2019 4:13:24 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision INFO: Excess workload after pending Kubernetes agents: 1 Mar 02, 2019 4:13:24 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision INFO: Template for label jfrog-cli-go: Kubernetes Pod Template Mar 02, 2019 4:13:24 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl apply INFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0 Mar 02, 2019 4:13:34 AM hudson.slaves.NodeProvisioner$2 run INFO: Kubernetes Pod Template provisioning successfully completed. We have now 3 computer(s) Mar 02, 2019 4:13:34 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch INFO: Created Pod: jfrog-cli-go-rb88g-96jd0 in namespace jenkins Mar 02, 2019 4:13:34 AM okhttp3.internal.platform.Platform log INFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path? Mar 02, 2019 4:13:44 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision INFO: Excess workload after pending Kubernetes agents: 1 Mar 02, 2019 4:13:44 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision INFO: Template for label jfrog-cli-go: Kubernetes Pod Template Mar 02, 2019 4:13:44 AM hudson.slaves.NodeProvisioner$StandardStrategyImpl apply INFO: Started provisioning Kubernetes Pod Template from common-operations with 1 executors. Remaining excess workload: 0 Mar 02, 2019 4:13:54 AM hudson.slaves.NodeProvisioner$2 run INFO: Kubernetes Pod Template provisioning successfully completed. We have now 4 computer(s) Mar 02, 2019 4:13:54 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch INFO: Created Pod: jfrog-cli-go-rb88g-j7qmx in namespace jenkins Mar 02, 2019 4:13:54 AM okhttp3.internal.platform.Platform log INFO: ALPN callback dropped: HTTP/2 is disabled. Is alpn-boot on the boot class path? Mar 02, 2019 4:14:00 AM com.squareup.okhttp.internal.Platform$JdkWithJettyBootPlatform getSelectedProtocol INFO: ALPN callback dropped:
[JIRA] (JENKINS-54170) Kubernetes agent does not connect on first several attempts
Title: Message Title John Jeffers created an issue Jenkins / JENKINS-54170 Kubernetes agent does not connect on first several attempts Issue Type: Bug Assignee: Carlos Sanchez Components: kubernetes-plugin Created: 2018-10-20 05:15 Environment: Jenkins 2.138.2 running in Kubernetes using jenkins/jenkins:2.138.2 image Kubernetes plugin 1.13.0 Priority: Minor Reporter: John Jeffers I'm seeing long wait times for kubernetes build slaves to run jobs. What appears to be happening is the Jenkins master is refusing connection, but eventually accepts, at which time the build slave registers and start running the job. Here's a representative example of logs from the JNLP container when this is happening. You will see several failed attempts to connect, then it accepts the connection. This is easily reproducible. Sometimes it connects relatively quickly, other times it takes 5 minutes or so before it finally accepts the connection. Warning: JnlpProtocol3 is disabled by default, use JNLP_PROTOCOL_OPTS to alter the behavior Oct 20, 2018 4:57:41 AM hudson.remoting.jnlp.Main createEngine INFO: Setting up agent: jenkins-slave-w5dwq-sdx28 Oct 20, 2018 4:57:41 AM hudson.remoting.jnlp.Main$CuiListener INFO: Jenkins agent is running in headless mode. Oct 20, 2018 4:57:41 AM hudson.remoting.Engine startEngine INFO: Using Remoting version: 3.23 Oct 20, 2018 4:57:41 AM hudson.remoting.Engine startEngine WARNING: No Working Directory. Using the legacy JAR Cache location: /home/jenkins/.jenkins/cache/jars Oct 20, 2018 4:57:41 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among https://jenkins.mycompany.com/ Oct 20, 2018 4:57:42 AM org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver resolve INFO: Remoting server accepts the following protocols: [JNLP4-connect,
