ovirt-engine master failure on test 008_basic_ui_sanity.initialize_chrome
Description
Activity

Eyal Edri December 25, 2018 at 2:21 PM
I’m not sure its worth investing time if it fails 0.05% of the time.
AFAIK test is passing for now and we don’t have a pending issue, so I’ll close this one for now.
If you have any ideas/suggestions to improve the UI test, feel free to submit a patch to OST \:)

Greg Sheremeta December 25, 2018 at 1:37 PM
It depends on how often it happens.
There are 2 things, generally, that can go wrong in the test. 1 gwt doesn't load at all, and 2 there are timeouts when waiting for gwt to change pages when menu items are clicked. we are pretty resilient when it comes to problem 2, but maybe .05% of time the graceful handling of this could fail. we don't deal with 1 other than silently fail the test at the beginning, and you have to look at the screenshot and take a guess that that's what happened. [I believe that's what happened above.]
So, the test could be more graceful. It can be upgraded to perform detection of this condition (gwt doesn't load) and do further inspection (is the gwt script there? is it valid javascript? can we try again? etc.)

Eyal Edri December 25, 2018 at 1:15 PM
@Greg Sheremeta @Dafna Ron is this still an issue worth investigating? race maybe?

Greg Sheremeta October 15, 2018 at 11:15 PM
perhaps the containers and browser start fine and simply the engine isn't running at 192.168.201.4/ovirt-engine/webadmin ?

Greg Sheremeta October 15, 2018 at 3:23 PM
right click view source on that
raise exception_class(message, screen, stacktrace)
'Message: timeout\n (Session info: chrome=64.0.3282.140)\n (Driver info: chromedriver=2.35.528139 (47ead77cb35ad2a9a83248b292151462a66cd881),platform=Linux 3.10.0-862.3.2.el7.x86_64 x86_64)\n\n-------------------- >> begin captured stdout << ---------------------\n
_init_browser, connecting to hub at http://172.18.0.2:4444/wd/hub
setting window size
navigating to engine at https://192.168.201.4/ovirt-engine/webadmin
---------------------
and then it times out. Seems like the browser isn't starting. The containers are up and did respond to wget's. Very odd.

Dafna Ron October 15, 2018 at 3:18 PM
Greg gave example and screen shots should be saved when basic suite is run under: artifact/basic-suite.el7.x86_64/screenshots/
it did not collect screen shots for this run:
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/10601/artifact/basic-suite.el7.x86_64/
@Barak Korren @Gal Ben Haim any idea why it would not collect the screenshots?
any other way for us to debug this in future?
Details
Assignee
infrainfraReporter
Dafna RonDafna Ron(Deactivated)Priority
High
Details
Details
Assignee

Reporter

I have seen random failures of test 008_basic_ui_sanity.initialize_chrome which are not related to the changes.
Here is the latest failure which I confirmed with didi is not a real failure and is not related to the change
https://gerrit.ovirt.org/#/c/89572/
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/10601/
I cannot see anything in the http logs and in engine logs.
I can see a warn on ssl and some issues which seems to be resolved later on domain names:
'[Mon Oct 15 02:56:26.041204 2018] [ssl:warn] [pid 18661] AH01909: RSA certificate configured for 192.168.201.4:443 does NOT include an ID which matches the server name'
I think the issue is the test since the only errors I can see are in the lago logs.
I saved logs to allow debugging of the test failure.
@Gal Ben Haim
@Greg Sheremeta
Can you please check this issue?