Bug 1542460

Summary:	When jenkins in one project and pipeline in other project. View log link points to wrong URL.
Product:	OpenShift Container Platform	Reporter:	Priyanka Kanthale <pkanthal>
Component:	Build	Assignee:	Gabe Montero <gmontero>
Status:	CLOSED ERRATA	QA Contact:	XiuJuan Wang <xiuwang>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.7.0	CC:	aos-bugs, bparees, gmontero, jmetso, jokerman, mmccomas, pkanthal
Target Milestone:	---
Target Release:	3.9.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: the openshift jenkins sync plugin assumed the jenkins service and pipeline strategy build were in the same project when constructing the build url for the openshfit console Consequence: when jenkins is in one project and pipeline strategy build in another project, the view log link in the openshift console points to wrong URL because if cannot find the jenkins service/route Fix: correct the openshift jenkins sync plugin to look for the jenkins service/route in the namespace it is running in; also lend greater precedence if the user has explicitly configured the root URL in jenkins Result: the URL for a given pipeline strategy build in the openshift console will now render correctly	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-27 18:01:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Priyanka Kanthale 2018-02-06 11:53:24 UTC

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

Comment 1 Gabe Montero 2018-02-09 21:15:42 UTC

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.

Comment 2 Ben Parees 2018-02-10 02:38:02 UTC

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.

Comment 3 Gabe Montero 2018-02-12 19:10:24 UTC

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.

Comment 4 Ben Parees 2018-02-15 13:54:10 UTC

Gabe, I moved this back to target 3.9.0...   were you not planning to deliver it until after 3.9.0 ships?

Comment 5 Gabe Montero 2018-02-15 14:28:11 UTC

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

Comment 6 Gabe Montero 2018-02-15 17:42:21 UTC

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.

Comment 7 Gabe Montero 2018-02-20 15:57:44 UTC

The 3.9 openshift jenkins rhel image should be available internally for QE to verify.

Moving to ON_QA

Comment 8 XiuJuan Wang 2018-02-23 07:08:34 UTC

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)

Comment 12 Ben Parees 2018-06-14 15:19:02 UTC

*** Bug 1591182 has been marked as a duplicate of this bug. ***

Comment 14 errata-xmlrpc 2018-06-27 18:01:32 UTC

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