@Troy

Create jenkins app with the new image jenkins:1.642-28(a414317f519d),the second job launched in jenkins webconsole always failed due to the below error. 

Webconsole Log:
<----------snip--------->
Exiting "Scale OpenShift Deployment" successfully, where the deployment "frontend-2" reached "1" replica(s).


Starting "Verify OpenShift Service" for the service "frontend" from the project "test".
  Attempting to connect to "172.31.86.34:8080" ...


Exiting "Verify OpenShift Service" unsuccessfully; a connection to "172.31.86.34:8080" could not be made.
Build step 'Verify OpenShift Service' marked build as failure
Finished: FAILURE
<----------snip------------>

But in cli, the frontend pod and service is ready. Could curl the frontend service in jenkins pod.Not sure what's wrong.

$ oc get  svc 
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
frontend        172.31.86.34     <none>        8080/TCP   17m
frontend-prod   172.31.35.49     <none>        8080/TCP   17m
jenkins         172.31.183.231   <none>        8080/TCP   19m
[wxj@dhcp-129-163 xiuwang]$ oc rsh jenkins-1-ybhr6 
sh-4.2$ curl 172.31.86.34:8080  | grep title
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 40213  100 40213    0     0  8481k      0 --:--:-- --:--:-- --:--:-- 9817k
  <title>Welcome to OpenShift</title>
sh-4.2$

While I can docker pull brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/jenkins-1-rhel7:1.642-28 onto my system, I am having trouble importing that image into my jenkins image stream (I have been able to do that in the past).  I believe I have the appropriate insecure registry settings for both my docker daemon and the image stream.

While I continue to investigate the issue with my test environment, I'd like to get two pieces of information from QA:

1) The json/yaml for the jenkins image stream that you used.

2) A repro of the problem being seen with verbose logging turned on for the "verify openshift service" step.  The specific java exception on the connection attempt could prove instructive.

NOTE: while I can't bring up the image in an openshift pod, I was able to bring it up in a docker container and confirm the correct version of the plugin is installed.

thanks,
gabe

Update: while I still can't import brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/jenkins-1-rhel7:1.642-28 into an ImageStream, I was able to run it external from OpenShift and manually provide the API endpoint / project / token.  Doing so, I was able to verify a running service repeatedly.

So to QA, please still provide 1) and 2) from #Comment 6.

Also, a confirmation that brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/jenkins-1-rhel7:1.642-28 is the correct image to be testing would be good too.

thanks,
gabe

Hi XiuJuan Wang,

First, yes, certainly this item with the verify openshift service build step should not block any security validations as noted in the title of this bug, or 3.2 ultimately shipping, so thanks for moving the bug to verify.

Next, thanks for the confirm on the image and info on how you imported it into your OpenShift.  Using that methodology, I was able to bring brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/jenkins-1-rhel7:1.642-28 (a414317f519d) in a Pod, etc.

However, I ran the job repeatedly and saw no issues.

As to your question as to why it is occurring for you, I go back to what I mentioned in item 2) in #Comment 7.  If we want to nail down why you are getting the failure, we need the verbose logging to see exactly what java exception is occurring.  I suspect it is something like a socket timeout, but let's get the data and go from there.  Based on the findings, if need be, most likely we can open a low sev, post 3.2 bugzilla to track workarounds (for example, if it is a socket timeout, we can see if making the socket connect timeout value configurable helps.

thanks again ... gabe

Hi,Gabe
Sometimes I can reproduce 2) in #comment 7, maybe the network is not stable between US and our office.
Anyway,I will keep an eye on this issue if it's a real problem.
Thanks!

Sounds good .... yeah, if I read you correctly and you are seeing it intermittently, I bet it is a connection timeout.  But keep an eye on it as you say and based on any data you capture we can go from there.
Thanks!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2016:0711