Bug 1150287 - Can not trigger jenkins build on RHEL6.6
Summary: Can not trigger jenkins build on RHEL6.6
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Containers
Version: 2.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Brenton Leanhardt
QA Contact: libra bugs
URL:
Whiteboard:
Depends On: 1127667 1131221 1150288
Blocks: 1145848 1146679
TreeView+ depends on / blocked
 
Reported: 2014-10-07 20:21 UTC by John W. Lamb
Modified: 2014-11-21 06:35 UTC (History)
20 users (show)

Fixed In Version: jenkins-plugin-openshift-0.6.25.1-0.el6op jenkins-1.565.3-1.el6op openshift-origin-cartridge-jenkins-1.16.2.2-1.el6op openshift-origin-cartridge-jenkins-client-1.17.2.2-1.el6op
Doc Type: Bug Fix
Doc Text:
Clone Of: 1127667
Environment:
Last Closed: 2014-10-17 21:20:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
jenkins log (9.73 KB, text/plain)
2014-10-10 06:01 UTC, Anping Li
no flags Details
jenkins log from jolamb test instance showing successful run (13.67 KB, text/plain)
2014-10-13 19:43 UTC, John W. Lamb
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBIDE-18454 0 Blocker Closed Cant connect to OpenShift running on RHEL 6.6 (javax.net.ssl.SSLException: Could not generate DH keypair) 2018-01-30 11:37:57 UTC
Red Hat Issue Tracker OSJC-125 0 Major Closed Allow users to remove DHE ciphers 2018-01-30 11:37:58 UTC

Comment 4 JBoss JIRA Server 2014-10-08 05:31:25 UTC
Marián Labuda <mlabuda> updated the status of jira JBIDE-18454 to Closed

Comment 7 Anping Li 2014-10-10 05:57:33 UTC
Failed QA, maybe OSE-2.0 and OSE-1.2 needn't the new jenkins packages.

old jdk: java-1.7.0-openjdk-1.7.0.65-2.5.1.2
new jdk: java-1.7.0-openjdk-1.7.0.71-2.5.3.1

old jenkins packages: jenkins-1.509.1-1.el6op.noarch,jenkins-plugin-openshift-0.6.25-1.el6op.x86_64,openshift-origin-cartridge-jenkins-1.16.1-2.el6op.noarch

New jenkins packages:  jenkins-1.565.3-1.el6op.noarch.rpm,jenkins-plugin-openshift-0.6.25.1-0.el6op.x86_64.rpm , openshift-origin-cartridge-jenkins-1.16.2.1-1.el6op.noarch.rpm

1) OSE 6.6,old jdk,old jenkins packages
    Result: php build success using jenkins

2) OSE 6.6,new jdk,old jenkins packages
    Result: php build success using jenkins

3) OSE 6.6,old jdk,New jenkins packages
    Result: php build fails with the following error message 

    WARNING: Cancelling build due to earlier exceptions
    com.openshift.client.InvalidCredentialsOpenShiftException: Your credentials are not authorized to access "https://broker.ose20-host.com.cn/broker/rest/user"

4) OSE 6.6,new jdk,New jenkins packages
    Result: php build fails with the following error message 

    WARNING: Cancelling build due to earlier exceptions
    com.openshift.client.InvalidCredentialsOpenShiftException: Your credentials are not authorized to access "https://broker.ose20-host.com.cn/broker/rest/user"

Comment 8 Anping Li 2014-10-10 06:01:09 UTC
Created attachment 945468 [details]
jenkins log

The jenkins log after 'build php app using jenkins'

Comment 9 Andre Dietisheim 2014-10-10 08:43:00 UTC
Reading the above results there's a pattern of authorization problems when using the new jenkins packages. Are  you sure that those are configured right? If so, we have a "new" problem either in jenkins packages or underlying openshift-java-client.

Comment 10 Johnny Liu 2014-10-10 09:33:06 UTC
I also encounter this issue, when I downgrade all the jenkins and jenkins plugin to previous released version, it is working well. Obviously this is a regression bug introduced by new packages.

Comment 11 John W. Lamb 2014-10-13 19:40:18 UTC
I cannot replicate this failure on RHEL 6.6. Here's my relevant packages:

  [root@broker ~]# rpm -qa | grep 'jenkins\|openjdk-1.7'
  openshift-origin-cartridge-jenkins-1.16.2.1-1.el6op.noarch
  jenkins-plugin-openshift-0.6.25.1-0.el6op.x86_64
  openshift-origin-cartridge-jenkins-client-1.17.1-2.el6op.noarch
  java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el6_5.x86_64
  jenkins-1.565.3-1.el6op.noarch
  
  [root@broker pt1]# git push
  Counting objects: 5, done.
  Delta compression using up to 2 threads.
  Compressing objects: 100% (3/3), done.
  Writing objects: 100% (3/3), 284 bytes, done.
  Total 3 (delta 2), reused 0 (delta 0)
  remote: Executing Jenkins build.
  remote:
  remote: You can track your build at https://jenkins-jlent20.ose20zscl11.example.com/job/pt1-build
  remote:
  remote: ERROR - Couldn't schedule job
  remote: !!!!!!!!
  remote: Deployment Halted!
  remote: If the build failed before the deploy step, your previous
  remote: build is still running.  Otherwise, your application may be
  remote: partially deployed or inaccessible.
  remote: Fix the build and try again.
  remote: !!!!!!!!
  remote: An error occurred executing 'gear postreceive' (exit code: 1)
  remote: Error message: Failed to execute: 'control post-receive' for /var/lib/openshift/543c2213c4ba086554000001/jenkins-client
  remote:
  remote: For more details about the problem, try running the command again with the '--trace' option.
  To ssh://543c2213c4ba086554000001.example.com/~/git/pt1.git/
     27bd3be..96b923e  master -> master

It looks like the jenkins job wasn't scheduled, but it in fact was. The reason the jenkins-client thinks it failed is because jenkins returned a "201 created" HTTP response instead of the expected 200 or 302:

  curl -s -w %{http_code} --output /dev/null -X POST --insecure https://${JENKINS_USERNAME}:${JENKINS_PASSWORD}@jenkins-jlent20.ose20zscl11.example.com/job/pt1-build/build
  201

In the jenkins log, we can see that the build did in fact run:

  ...
  Oct 13, 2014 3:15:38 PM hudson.slaves.NodeProvisioner update
  INFO: pt1-build provisioningE successfully completed. We have now 2 computer(s)
  Oct 13, 2014 3:15:45 PM hudson.plugins.openshift.OpenShiftComputerLauncher launch
  INFO: Slave connected.
  Oct 13, 2014 3:16:04 PM hudson.model.Run execute
  INFO: pt1-build #1 main build action completed: SUCCESS

I'll attach the full jenkins log in a moment.

Comment 12 John W. Lamb 2014-10-13 19:43:17 UTC
Created attachment 946583 [details]
jenkins log from jolamb test instance showing successful run

Comment 13 Ben Parees 2014-10-13 19:46:57 UTC
Yeah, I mentioned to Jason the other PR needed to fix the response code handling.  (Don't have it handy but hopefully he does now)

Comment 14 Anping Li 2014-10-14 05:10:27 UTC
Using the updated environment( was updated from old puddle), The issue reported in comment 7 still exists.

Using new installation of ose-2.0 puddle-2014-10-13-3, I got same result as Comment 11.
"ERROR - Couldn't schedule job ***" is so obvious error. I am waiting the other fixed PR.

I will dig more about What's the difference between update Env and new installation Env.

Comment 16 JBoss JIRA Server 2014-10-14 19:38:57 UTC
Andre Dietisheim <adietish> updated the status of jira JBIDE-18454 to Reopened

Comment 17 JBoss JIRA Server 2014-10-14 19:39:10 UTC
Andre Dietisheim <adietish> updated the status of jira JBIDE-18454 to Resolved

Comment 18 JBoss JIRA Server 2014-10-14 19:39:18 UTC
Andre Dietisheim <adietish> updated the status of jira JBIDE-18454 to Closed

Comment 19 JBoss JIRA Server 2014-10-16 09:58:14 UTC
Andre Dietisheim <adietish> updated the status of jira JBIDE-18454 to Reopened

Comment 20 John W. Lamb 2014-10-16 18:16:22 UTC
Just an update, I still can't figure out why the different 2.0 envs are seeing different behavior. The relevant packages are all the same, etc.

Running some more tests today, since even though the issue this fix is supposed to addressed has probably passed for most users, this still needs to be sorted out for future jenkins updates.

Comment 21 John W. Lamb 2014-10-16 18:50:21 UTC
Anping, can you tell me what puddle version of OSE 2.0 your test env was upgraded from? Without knowing that, I'm not sure I can reproduce your issue.

Comment 22 Anping Li 2014-10-17 03:06:54 UTC
The prior version is ose-2.0-2014-10-06.2.

Comment 23 Anping Li 2014-10-17 09:32:52 UTC
Today, I also can't reproduced the issue in the build which is upgraded from the GA build to puddle 2014-10-16.4; unlucky the Environment hit the issue have been removed. I suggest close it or downgrade it if no one can reproduced.

Comment 24 Johnny Liu 2014-10-17 15:42:04 UTC
According to comment 23, this bug is not reproduced now, but still need update Cartridge-Version field in the manifest.yml file just like what we did in 2.1 (BZ#1153317)


Note You need to log in before you can comment on or make changes to this bug.