Red Hat Bugzilla – Bug 876465
Embedding scalable app (php) with jenkins fails to create a new builder (only via web)
Last modified: 2017-03-08 12:34 EST
Created attachment 644657 [details] screenshot wirh error message Description of problem: Adding Jenkins support for an app fails with attached message. This only happens if there is no Jenkins server available and user tries to create a new one. If there is already Jenkins server available the builder is created successfully. The CLI works without any issues. Version-Release number of selected component (if applicable): onpremise-2012-11.12 How reproducible: always through WEB and missing jenkins server Steps to Reproduce: 1. create scalable app (make sure you have no jenkins server) 2. embed with jenkins 3. Actual results: Expected results: Additional info:
Web Console is in tech preview for 1.0 - this needs to be fixed but can be done in a dot release.
I attempted to recreate this issue on the latest OSE packages. I think I'm going to need more details on the steps to reproduce the issue. Here is what I did to attempt the recreation. 1. Set up a single server with the broker and node both installed. 2. Created a scaled application using the rhc cli. I used the cli since you need to do so for the -s option. rhc app create -s phptest php-5.3 3. Log-in to the web console, go to 'My Application', go to the details of the phptest application, click on 'Enable Jenkins Builds'. 4. Since there is no jenkins server yet, I am prompted to create a jenkins server, so I do. 5. Once that is done, the jenkins cartridge has been added to the application. Additional test: I created a second php application and added the existing jenkins cartridge to the application successfully.
I have tried several times, find that in the bad network or high load environment, the mcollective timeout is short. Then it will reproduce this bug. In the file /etc/openshift/plugins.d/openshift-origin-msg-broker-mcollective.conf, update MCOLLECTIVE_TIMEOUT=100 or bigger, then the bug can't be reproduced.
In hosted, we've made the mcollective timeout 180s for stability reasons.
Should we just document this in the troubleshooting guide, since we are probably not going to be able to tell the broker to go faster under load of if there are network connectivity issues.
I think want to increase our default mcollective timeout. The troubleshooting guide would be a good place to document general slowness issues. We can link to reference architectures that provide greater scalability.
Rob, do you know if there any reason we shouldn't replicate the hosted setting as the default?
This configuration change has been merged upstream. https://github.com/openshift/origin-server/pull/972
Verify: Create jenkins server successfully Version: http://buildvm-devops.usersys.redhat.com/puddle/build/OpenShiftEnterprise/1.1.x/2012-12-09.1/
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. http://rhn.redhat.com/errata/RHSA-2013-0220.html