Hi Hong,

Here is the detail of the Environment 
Installed k8s and Jenkins on the one Master server (Linux) and the jobs are 
running on Master.(with out slave nodes)
But when we tried on 1 Master and 2 slave nodes , the jobs are failing with 
error 
=============
Nov 16, 2017 6:22:51 AM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Failed to connect to 
http://slc13pef.us.oracle.com:8080/tcpSlaveAgentListener/: 
slc13pef.us.oracle.com
java.io.IOException: Failed to connect to 
http://slc13pef.us.oracle.com:8080/tcpSlaveAgentListener/: 
slc13pef.us.oracle.com
        at 
org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:161)
        at hudson.remoting.Engine.innerRun(Engine.java:495)
        at hudson.remoting.Engine.run(Engine.java:447)
Caused by: java.net.UnknownHostException: slc13pef.us.oracle.com
==================
Here we installed Jenkins and not using as a service.
Regards,
Basanta

On Tuesday, November 21, 2017 at 10:01:24 AM UTC+5:30, pbasan...@gmail.com 
wrote:
>
> Hi Hong,
> We are using Linux machine 
> But i think the issue reported on this thread is nothing to do with 
> Operating System.
> Regards,
> Basanta
>
> On Monday, November 20, 2017 at 9:13:08 PM UTC+5:30, YAN-HONG WANG wrote:
>>
>> Hello,
>>
>> Do you use Ubuntu machine to be your base?
>>
>> Hong
>>
>> Am Montag, 20. November 2017 12:14:02 UTC+1 schrieb pbasan...@gmail.com:
>>>
>>> Hi Hong,
>>> We are hitting the Same error as mentioned above .. Can you please share 
>>> the steps followed to resolve this error.
>>> =============
>>> Nov 16, 2017 6:22:51 AM hudson.remoting.jnlp.Main$CuiListener error
>>> SEVERE: Failed to connect to 
>>> http://slc13pef.us.oracle.com:8080/tcpSlaveAgentListener/: 
>>> slc13pef.us.oracle.com
>>> java.io.IOException: Failed to connect to 
>>> http://slc13pef.us.oracle.com:8080/tcpSlaveAgentListener/: 
>>> slc13pef.us.oracle.com
>>>         at 
>>> org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:161)
>>>         at hudson.remoting.Engine.innerRun(Engine.java:495)
>>>         at hudson.remoting.Engine.run(Engine.java:447)
>>> Caused by: java.net.UnknownHostException: slc13pef.us.oracle.com
>>>  
>>> ==================
>>> Regards,
>>> Basanta
>>>
>>>
>>> On Thursday, October 12, 2017 at 5:40:36 PM UTC+5:30, YAN-HONG WANG 
>>> wrote:
>>>>
>>>> Hello Carlos,
>>>>
>>>> I fixed problem already.
>>>> Thanks.
>>>>
>>>> Hong
>>>>
>>>> Am Dienstag, 10. Oktober 2017 14:26:47 UTC+2 schrieb YAN-HONG WANG:
>>>>>
>>>>> Hello Carlos,
>>>>>
>>>>> In containerTemplate, I define one container "worker".
>>>>>
>>>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>> $ kubectl --namespace=build-env exec -it slave-0cnkz-gv0bg 
>>>>> --container=worker *cat /etc/resolv.conf* 
>>>>>
>>>>>
>>>>> *nameserver 10.96.0.10search build-env.svc.cluster.local 
>>>>> svc.cluster.local cluster.localoptions ndots:5*
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>> *FQDN*
>>>>> $ kubectl --namespace=build-env exec -it slave-0cnkz-gv0bg 
>>>>> --container=worker nslookup *jenkins.build-env.svc.cluster.local*
>>>>> nslookup: can't resolve '(null)': Name does not resolve
>>>>>
>>>>>
>>>>> *nslookup: can't resolve 'jenkins.build-env.svc.cluster.local': Try 
>>>>> againcommand terminated with exit code 1*
>>>>>
>>>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>> And then I append one "*dot*" in the end of jenkins service url
>>>>>
>>>>> $ kubectl --namespace=build-env exec -it slave-0cnkz-gv0bg 
>>>>> --container=worker nslookup *jenkins.build-env.svc.cluster.local.*
>>>>> nslookup: can't resolve '(null)': Name does not resolve
>>>>>
>>>>>
>>>>> *Name:      jenkins.build-env.svc.cluster.local.Address 1: 
>>>>> 10.100.146.119 jenkins.build-env.svc.cluster.local*
>>>>>
>>>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>> $ kubectl --namespace=build-env exec -it slave-0cnkz-gv0bg 
>>>>> --container=worker nslookup *jenkins.build-env*
>>>>> nslookup: can't resolve '(null)': Name does not resolve
>>>>>
>>>>>
>>>>> *Name:      jenkins.build-envAddress 1: 10.100.146.119*
>>>>>
>>>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>> kubectl --namespace=build-env exec -it slave-0cnkz-gv0bg 
>>>>> --container=worker *curl 
>>>>> http://jenkins.build-env:8080/tcpSlaveAgentListener/ 
>>>>> <http://jenkins.build-env:8080/tcpSlaveAgentListener/>*
>>>>>
>>>>>
>>>>> *  Jenkins*
>>>>>
>>>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>> So do you know why FQDN can't be resolved by DNS?
>>>>> JNLP is also in the same pod.
>>>>> Suppose that JNLP container and worker container should have the same 
>>>>> behavior, right?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Hong
>>>>>
>>>>> Am Freitag, 6. Oktober 2017 10:21:09 UTC+2 schrieb YAN-HONG WANG:
>>>>>>
>>>>>> Hello Carlos,
>>>>>>
>>>>>> Thanks for reply again.
>>>>>> And I obviously have jenkins service expose in namespace "build-env".
>>>>>>
>>>>>> $ kubectl --namespace=build-env get *service*
>>>>>> NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   
>>>>>> PORT(S)                                         AGE
>>>>>> *jenkins   *NodePort   10.98.101.107   <none>        
>>>>>> *8080*:30808/TCP,8443:30443/TCP,50000:30500/TCP   
>>>>>> 15h
>>>>>>
>>>>>> In my working environment, there are seems some DNS issue.
>>>>>> So for example, I use this short workaround to deploy in my 
>>>>>> jenkins.yaml.
>>>>>> and then "*Test Connection*" can "*Connection successful*"
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------------
>>>>>> hostAliases:
>>>>>> - ip: "10.96.0.1"
>>>>>>   hostnames:
>>>>>>   - "kubernetes.default.svc.cluster.local"
>>>>>>
>>>>>> ------------------------------------------------------------------------------------
>>>>>>
>>>>>> So in podTemplate, is there any similar syntax like above?
>>>>>> And that could solve *jenkins.build-env.svc.cluster.local* naming 
>>>>>> issue in container JNLP of slave?
>>>>>>
>>>>>> But, if the service ip address of Jenkins is not static, that is 
>>>>>> still a problem in my environment...
>>>>>> Thanks.
>>>>>>
>>>>>> Hong
>>>>>>
>>>>>>
>>>>>> Am Donnerstag, 5. Oktober 2017 17:16:00 UTC+2 schrieb Carlos Sanchez:
>>>>>>>
>>>>>>> you are correct your kubernetes DNS can't resolve the name, assuming 
>>>>>>> you have a service jenkins in the build-env namespace
>>>>>>>
>>>>>>> On Thu, Oct 5, 2017 at 4:09 PM, WANG, YAN-HONG <allway...@gmail.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> My environment:
>>>>>>>> Jenkins: 2.73.1
>>>>>>>> Jenkins plugin (kubernetes: *1.0*).
>>>>>>>> Kuberntes Server: *v1.7.7* ( One master and one minion)
>>>>>>>> Platform: Ubuntu 16.04 (in *Synnefo *cluster environment)
>>>>>>>>
>>>>>>>> When I execute pipeline job with kubernetes plugin in Jenkins 
>>>>>>>> environment.
>>>>>>>>
>>>>>>>> The slave-jksnf-q6dlr is stay in "offline" state.
>>>>>>>>
>>>>>>>> *$ ​kubectl --namespace=build-env logs slave-jksnf-q6dlr jnlp*
>>>>>>>> Warning: JnlpProtocol3 is disabled by default, use 
>>>>>>>> JNLP_PROTOCOL_OPTS to alter the behavior
>>>>>>>> Warning: SECRET is defined twice in command-line arguments and the 
>>>>>>>> environment variable
>>>>>>>> Warning: AGENT_NAME is defined twice in command-line arguments and 
>>>>>>>> the environment variable
>>>>>>>> Oct 05, 2017 1:29:32 PM hudson.remoting.jnlp.Main createEngine
>>>>>>>> INFO: Setting up slave: slave-jksnf-q6dlr
>>>>>>>> Oct 05, 2017 1:29:32 PM hudson.remoting.jnlp.Main$CuiListener <init>
>>>>>>>> INFO: Jenkins agent is running in headless mode.
>>>>>>>> Oct 05, 2017 1:29:32 PM hudson.remoting.Engine startEngine
>>>>>>>> WARNING: No Working Directory. Using the legacy JAR Cache location: 
>>>>>>>> /home/jenkins/.jenkins/cache/jars
>>>>>>>> Oct 05, 2017 1:29:32 PM hudson.remoting.jnlp.Main$CuiListener status
>>>>>>>> INFO: Locating server among [
>>>>>>>> http://jenkins.build-env.svc.cluster.local:8080/]
>>>>>>>> Oct 05, 2017 1:29:37 PM hudson.remoting.jnlp.Main$CuiListener error
>>>>>>>> SEVERE: Failed to connect to 
>>>>>>>> http://jenkins.build-env.svc.cluster.local:8080/tcpSlaveAgentListener/:
>>>>>>>>  
>>>>>>>> jenkins.build-env.svc.cluster.local
>>>>>>>> java.io.IOException: Failed to connect to 
>>>>>>>> http://jenkins.build-env.svc.cluster.local:8080/tcpSlaveAgentListener/:
>>>>>>>>  
>>>>>>>> jenkins.build-env.svc.cluster.local
>>>>>>>>     at 
>>>>>>>> org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:161)
>>>>>>>>     at hudson.remoting.Engine.innerRun(Engine.java:495)
>>>>>>>>     at hudson.remoting.Engine.run(Engine.java:447)
>>>>>>>> Caused by: java.net.UnknownHostException: 
>>>>>>>> jenkins.build-env.svc.cluster.local
>>>>>>>>     at java.net
>>>>>>>> .AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
>>>>>>>>     at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>>>>>>>     at java.net.Socket.connect(Socket.java:589)
>>>>>>>>     at sun.net.NetworkClient.doConnect(NetworkClient.java:175)
>>>>>>>>     at sun.net.www.http.HttpClient.openServer(HttpClient.java:463)
>>>>>>>>     at sun.net.www.http.HttpClient.openServer(HttpClient.java:558)
>>>>>>>>     at sun.net.www.http.HttpClient.<init>(HttpClient.java:242)
>>>>>>>>     at sun.net.www.http.HttpClient.New(HttpClient.java:339)
>>>>>>>>     at sun.net.www.http.HttpClient.New(HttpClient.java:357)
>>>>>>>>     at 
>>>>>>>> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1202)
>>>>>>>>     at 
>>>>>>>> sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1138)
>>>>>>>>     at 
>>>>>>>> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1032)
>>>>>>>>     at 
>>>>>>>> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:966)
>>>>>>>>     at 
>>>>>>>> org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:158)
>>>>>>>>     ... 2 more
>>>>>>>>
>>>>>>>> It looks seem DNS can't solve name issue? or?
>>>>>>>> But, in minikube environment, there is no this problem...
>>>>>>>>
>>>>>>>> Thanks very much.
>>>>>>>>
>>>>>>>> Hong
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> You received this message because you are subscribed to the Google 
>>>>>>>> Groups "Jenkins Users" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>>>> send an email to jenkinsci-use...@googlegroups.com.
>>>>>>>> To view this discussion on the web visit 
>>>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/CADLWyO2XJG-50ouKNe7yVm6BiQ_-cYoxQQrWg7P2iRRX7FZ%3DAA%40mail.gmail.com
>>>>>>>>  
>>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/CADLWyO2XJG-50ouKNe7yVm6BiQ_-cYoxQQrWg7P2iRRX7FZ%3DAA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>> .
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>> Am Freitag, 6. Oktober 2017 10:21:09 UTC+2 schrieb YAN-HONG WANG:
>>>>>>
>>>>>> Hello Carlos,
>>>>>>
>>>>>> Thanks for reply again.
>>>>>> And I obviously have jenkins service expose in namespace "build-env".
>>>>>>
>>>>>> $ kubectl --namespace=build-env get *service*
>>>>>> NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   
>>>>>> PORT(S)                                         AGE
>>>>>> *jenkins   *NodePort   10.98.101.107   <none>        
>>>>>> *8080*:30808/TCP,8443:30443/TCP,50000:30500/TCP   
>>>>>> 15h
>>>>>>
>>>>>> In my working environment, there are seems some DNS issue.
>>>>>> So for example, I use this short workaround to deploy in my 
>>>>>> jenkins.yaml.
>>>>>> and then "*Test Connection*" can "*Connection successful*"
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------------
>>>>>> hostAliases:
>>>>>> - ip: "10.96.0.1"
>>>>>>   hostnames:
>>>>>>   - "kubernetes.default.svc.cluster.local"
>>>>>>
>>>>>> ------------------------------------------------------------------------------------
>>>>>>
>>>>>> So in podTemplate, is there any similar syntax like above?
>>>>>> And that could solve *jenkins.build-env.svc.cluster.local* naming 
>>>>>> issue in container JNLP of slave?
>>>>>>
>>>>>> But, if the service ip address of Jenkins is not static, that is 
>>>>>> still a problem in my environment...
>>>>>> Thanks.
>>>>>>
>>>>>> Hong
>>>>>>
>>>>>>
>>>>>> Am Donnerstag, 5. Oktober 2017 17:16:00 UTC+2 schrieb Carlos Sanchez:
>>>>>>>
>>>>>>> you are correct your kubernetes DNS can't resolve the name, assuming 
>>>>>>> you have a service jenkins in the build-env namespace
>>>>>>>
>>>>>>> On Thu, Oct 5, 2017 at 4:09 PM, WANG, YAN-HONG <allway...@gmail.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> My environment:
>>>>>>>> Jenkins: 2.73.1
>>>>>>>> Jenkins plugin (kubernetes: *1.0*).
>>>>>>>> Kuberntes Server: *v1.7.7* ( One master and one minion)
>>>>>>>> Platform: Ubuntu 16.04 (in *Synnefo *cluster environment)
>>>>>>>>
>>>>>>>> When I execute pipeline job with kubernetes plugin in Jenkins 
>>>>>>>> environment.
>>>>>>>>
>>>>>>>> The slave-jksnf-q6dlr is stay in "offline" state.
>>>>>>>>
>>>>>>>> *$ ​kubectl --namespace=build-env logs slave-jksnf-q6dlr jnlp*
>>>>>>>> Warning: JnlpProtocol3 is disabled by default, use 
>>>>>>>> JNLP_PROTOCOL_OPTS to alter the behavior
>>>>>>>> Warning: SECRET is defined twice in command-line arguments and the 
>>>>>>>> environment variable
>>>>>>>> Warning: AGENT_NAME is defined twice in command-line arguments and 
>>>>>>>> the environment variable
>>>>>>>> Oct 05, 2017 1:29:32 PM hudson.remoting.jnlp.Main createEngine
>>>>>>>> INFO: Setting up slave: slave-jksnf-q6dlr
>>>>>>>> Oct 05, 2017 1:29:32 PM hudson.remoting.jnlp.Main$CuiListener <init>
>>>>>>>> INFO: Jenkins agent is running in headless mode.
>>>>>>>> Oct 05, 2017 1:29:32 PM hudson.remoting.Engine startEngine
>>>>>>>> WARNING: No Working Directory. Using the legacy JAR Cache location: 
>>>>>>>> /home/jenkins/.jenkins/cache/jars
>>>>>>>> Oct 05, 2017 1:29:32 PM hudson.remoting.jnlp.Main$CuiListener status
>>>>>>>> INFO: Locating server among [
>>>>>>>> http://jenkins.build-env.svc.cluster.local:8080/]
>>>>>>>> Oct 05, 2017 1:29:37 PM hudson.remoting.jnlp.Main$CuiListener error
>>>>>>>> SEVERE: Failed to connect to 
>>>>>>>> http://jenkins.build-env.svc.cluster.local:8080/tcpSlaveAgentListener/:
>>>>>>>>  
>>>>>>>> jenkins.build-env.svc.cluster.local
>>>>>>>> java.io.IOException: Failed to connect to 
>>>>>>>> http://jenkins.build-env.svc.cluster.local:8080/tcpSlaveAgentListener/:
>>>>>>>>  
>>>>>>>> jenkins.build-env.svc.cluster.local
>>>>>>>>     at 
>>>>>>>> org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:161)
>>>>>>>>     at hudson.remoting.Engine.innerRun(Engine.java:495)
>>>>>>>>     at hudson.remoting.Engine.run(Engine.java:447)
>>>>>>>> Caused by: java.net.UnknownHostException: 
>>>>>>>> jenkins.build-env.svc.cluster.local
>>>>>>>>     at java.net
>>>>>>>> .AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
>>>>>>>>     at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>>>>>>>     at java.net.Socket.connect(Socket.java:589)
>>>>>>>>     at sun.net.NetworkClient.doConnect(NetworkClient.java:175)
>>>>>>>>     at sun.net.www.http.HttpClient.openServer(HttpClient.java:463)
>>>>>>>>     at sun.net.www.http.HttpClient.openServer(HttpClient.java:558)
>>>>>>>>     at sun.net.www.http.HttpClient.<init>(HttpClient.java:242)
>>>>>>>>     at sun.net.www.http.HttpClient.New(HttpClient.java:339)
>>>>>>>>     at sun.net.www.http.HttpClient.New(HttpClient.java:357)
>>>>>>>>     at 
>>>>>>>> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1202)
>>>>>>>>     at 
>>>>>>>> sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1138)
>>>>>>>>     at 
>>>>>>>> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1032)
>>>>>>>>     at 
>>>>>>>> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:966)
>>>>>>>>     at 
>>>>>>>> org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:158)
>>>>>>>>     ... 2 more
>>>>>>>>
>>>>>>>> It looks seem DNS can't solve name issue? or?
>>>>>>>> But, in minikube environment, there is no this problem...
>>>>>>>>
>>>>>>>> Thanks very much.
>>>>>>>>
>>>>>>>> Hong
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> You received this message because you are subscribed to the Google 
>>>>>>>> Groups "Jenkins Users" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>>>> send an email to jenkinsci-use...@googlegroups.com.
>>>>>>>> To view this discussion on the web visit 
>>>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/CADLWyO2XJG-50ouKNe7yVm6BiQ_-cYoxQQrWg7P2iRRX7FZ%3DAA%40mail.gmail.com
>>>>>>>>  
>>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/CADLWyO2XJG-50ouKNe7yVm6BiQ_-cYoxQQrWg7P2iRRX7FZ%3DAA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>> .
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/465bcdfe-6823-4d2b-84cf-cbbdd17ffc22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to