Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1760003

Summary: [OCP42 - migration UI] mig-ui failed to show migration logs
Product: OpenShift Container Platform Reporter: Tarun Patel <tapatel>
Component: Migration ToolingAssignee: Danil Grigorev <dgrigore>
Status: CLOSED ERRATA QA Contact: Xin jiang <xjiang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.2.0CC: chezhang, dgrigore, ernelson, sregidor, xjiang
Target Milestone: ---Flags: dgrigore: needinfo+
Target Release: 4.3.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-06 20:20:44 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:
Bug Depends On:    
Bug Blocks: 1759663    
Attachments:
Description Flags
Screen shot of web UI failure
none
console error none

Description Tarun Patel 2019-10-09 15:58:10 UTC
Created attachment 1623849 [details]
Screen shot of web UI failure

Description of problem:
Logs button on mig-ui fail to show logs

Version-Release number of selected component (if applicable):
4.2

How reproducible:
Everytime


Steps to Reproduce:
1. Configure mig-ui with OCP3.11 and OCP 42 cluster for migration.
2. Setup S3 bucket registry 
3. Create migPlan and start migration.
4. From mig-ui dashboard, Click on 3 dots at the end and click "logs" button.


Actual results:

From Web Console Log : 

app.bundle.js:61 TypeError: Cannot read property 'metadata' of undefined
    at g (app.bundle.js:61)
    at g.next (<anonymous>)
    at m (app.bundle.js:289)
    at l (app.bundle.js:289)
g @ app.bundle.js:61
m @ app.bundle.js:289
l @ app.bundle.js:289
Promise.then (async)
A @ app.bundle.js:289
(anonymous) @ app.bundle.js:289
h @ app.bundle.js:289
m @ app.bundle.js:289
l @ app.bundle.js:289
.
.
.
Show 18 more frames


Expected results:
mig-ui should show logs on UI


Additional info:

Comment 1 Danil Grigorev 2019-10-11 09:17:05 UTC
Hello, following your steps did not reveal any issues with logs on my fresh setup of 3.11 and 4.2 clusters. Could you give an environment reproducer, or more detailed info?

Comment 3 Zhang Cheng 2019-10-15 09:36:30 UTC
Xin Jiang
As I know we have reproduced this issue in our side. Could you help to provide more detail info in here? Thanks.

Comment 4 Xin jiang 2019-10-15 10:12:44 UTC
Cheng, It just happened once on our cluster. After that, it never reproduced.

Comment 5 Zhang Cheng 2019-10-15 10:33:33 UTC
Hi, Tarun

Could you help to provide more detail info for reproduce? Thanks.

Comment 6 Tarun Patel 2019-10-15 12:12:17 UTC
Hi All,

I am able to reproduce this issue consistently in my environment. Following is my mig-url installed on OCP42 cluster.

https://migration-openshift-migration.apps.ocp42-bm-cluster.dsal.lab.eng.rdu2.redhat.com/
user : kubeadmin
password : Sent in email to Xin, Cheng John and Danil

Thanks,
Tarun

Comment 7 John Matthews 2019-12-12 12:29:00 UTC
We need help to identify how to reproduce or we need to see details from javascript console related to exceptions, something so we can narrow down what might be wrong.

Comment 8 Xin jiang 2019-12-16 09:01:10 UTC
Created attachment 1645519 [details]
console error

Comment 9 Xin jiang 2019-12-16 09:05:01 UTC
I am able to reproduce this issue on 3.11->4.2. Below is the error message captured from Chrome Developer Tools. You also can check the screenshot above.

OPTIONS https://ec2-52-90-73-194.compute-1.amazonaws.com:8443/api/v1/namespaces/openshift-migration/pods?labelSelector=component%3Dvelero net::ERR_CERT_AUTHORITY_INVALID

Comment 10 Xin jiang 2019-12-16 10:14:10 UTC
BTW, the App Mig we installed is 1.0.0 Redhat Official Operator Source.

Comment 11 Sergio 2019-12-16 11:31:57 UTC
It seems that the problem is happening because of the certificates.

When we try to recover the logs from a migration plan, we communicate with target and source clusters. But when we login to app-migration, we only accept target's certificate. Source's certificate is accepted only when we create a migration plan for the first time, if the user in app-migration has never created a migration plan (migration plan has been created by any other user), source's certificate is not accepted in his browser.

In this situation (only target's certificate accepted) when we try to read a migration plan's logs, the application fails and says "Failed to fetch logs".

Once accepted the source's certificate too, the logs can be viewed.

Maybe, if source's certificate is not already accepted by the user, he should be redirected so that he can accept it instead of directly failing.

Comment 12 Danil Grigorev 2020-01-10 12:59:56 UTC
Bundle of PRs to fix: 

1) UI: https://github.com/fusor/mig-ui/pull/640
2) mig-controller: https://github.com/fusor/mig-controller/pull/380
3) operator: https://github.com/fusor/mig-operator/pull/189

Those introduced the discovery service in the stack, and contained the fix for the bug.

Comment 14 Sergio 2020-01-22 13:17:16 UTC
Verified in CAM 1.1 stage
Controller:
    image: registry.stage.redhat.io/rhcam-1-1/openshift-migration-controller-rhel8@sha256:ec015e65da93e800a25e522473793c277cd0d86436ab4637d73e2673a5f0083d
UI:
    image: registry.stage.redhat.io/rhcam-1-1/openshift-migration-ui-rhel8@sha256:ecd81e11af0a17bfdd4e6afce1bf60f422115ed3545ad2b0d055f0fded87e422

Now, when we login to App Migration for the first time and there are already existing plans in this App Migration. If we try to see the logs of a migration plan without ever creating a migration plan before, we are prompted to add a security exception regarding the "discovery" url instead of showing an error in the logs screen. Once accepted this url, we can see the logs without problems.

Comment 16 errata-xmlrpc 2020-02-06 20:20:44 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/RHEA-2020:0440