Description of problem: When configured jenkins in one project and pipeline in another project. The view log link points to wrong URL. The link referencing is the service name jenkins instead of the route hostname. How reproducible: First, you would need to disable automatic instantiation of the Jenkins instance within a project whenever a JenkinsPipeline build type is added. This is accomplished by setting the autoProvisionEnabled to false within the master-config.yaml file Next, you would need to configure the OpenShift sync plugin within Jenkins to specify the project that should be monitored. However, depending on the SDN plugin configured within OpenShift, join the projects Steps to Reproduce: 1. 2. 3. Actual results: View log points to service name jenkins instead of the route hostname. Expected results: View log should redirect to route hostname Additional info: SDN pulgin used is ovs-networkpolicy
OK, I was able to bring up https://access.redhat.com/support/cases/01989634 and got the additional context needed (the description was lacking in this regard). The customer is correct in that the service is involved, and the code currently assumes that the service is called "jenkins" and is in the same project as the build, which is not the case for the scenario the customer is employing, and tries to get the route associated with that service. If possible, the jenkins pod logs would be helpful. Given this disconnect, I would expect one of these logs to show up that start with "Could not find Route for service ... ". Confirmation of this would be great if possible. Whether the customer happens to have other services in the build's project that is named jenkins might interfere with things. I could not find any data around the services in the build namespace in the support case. Pending that confirmation, the minimal fix I believe is straight forward for when we are running in a pod - simply use the namespace mounted in the pod for the service lookup. Also need to do some regression testing that when we are running outside a pod, we do in fact use the fall back plan, which is the root url configured in jenkins. However, should we do anything with the fact the plugin assumes the jenkins service name is called "jenkins" ... should we allow this to be configurable? I'll discuss this internally here at development and report back when we have a conclusion. Lastly, as a side note, our friends at OpenShift IO have been asking about making the root URL tuneable via environment variables as well. So yeah, an area of focus has emerged.
Priyanka please see Gabe's questions above for more information about the customer's environment. Gabe, yes it seems like making the service name configurable in the sync plugin will like be desired by someone down the road, I don't know that it's immediately pressing though. I agree that looking for the service in the jenkins pod's project instead of the build's project seems like the right immediate action.
First, I sorted out why "https://jenkins" was the root url in the customer's env after a second glance in the code; it lines up with my earlier findings. So I don't need that additional information from the customer. Next, the sync plugin PR with the immediate fix: https://github.com/openshift/jenkins-sync-plugin/pull/198 Once it is merged, I'll be cutting v1.0.3 of the openshift-sync plugin. If the customer is amenable to getting a plugin fix from the jenkins update center, they can look for v1.0.3 and try it when it is available. This will be part of the openshift jenkins centos image soon after v1.0.3 is ready. I'll update this bugzilla when that occurs. Otherwise, it will be part of the openshift jenkins rhel image once v3.9 GAs...March 2018 is the current target there. Reminder, the customer should be able to upgrade his jenkins image to 3.9 even if his openshift master remains at 3.7.
Gabe, I moved this back to target 3.9.0... were you not planning to deliver it until after 3.9.0 ships?
Hey - yeah, per the PR discussion, since we decided to hold the change until after 3.9 shipped, I thought it better to set a target date that reflected it would drop after 3.9 went out. Since there is no 3.10 target date yet, I went with 3.9.z
I got this confused with the other multi-project bug (with client plugin in that case) Ben. Sorry for the confusion. This sync plugin change is in 3.9. The centos image is already updated. And the the rhel plugin rpm was updated with https://buildvm.openshift.eng.bos.redhat.com:8443/job/devex/job/devex%252Fjenkins-plugins/27/ So this should be available for QE to validate. Moving to modified.
The 3.9 openshift jenkins rhel image should be available internally for QE to verify. Moving to ON_QA
1.Create sample-pipeline bc without jenkins pod running in p1 project 2.Create jenkins server in p2 project 3.Configure the OpenShift sync plugin within Jenkins to specify the p1 project 4.Create a jenkins sa in p1, and add a token to the OpenShift sync plugin within Jenkins 5.Start a pipeline build, check 'view log' link in openshift webconsole. The 'view log' link to p2's jenkins route,can't reproduce this bug any more. Verified this bug with jenkins-2-rhel7(image id 5ce2c850fca8)
*** Bug 1591182 has been marked as a duplicate of this bug. ***
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-2018:2013