- Devel - oVirt List Archives

[ OST Failure Report ] [ oVirt Master (otopi+imgbased) ] [ 11-05-2018 ] [ 001_initialize_engine.test_initialize_engine ]
by Dafna Ron 11 May '18

11 May '18

Hi, We are failing in 001_initialize_engine.test_initialize_engine in the upgrade suite. the issue seems to be related to ovn configuration. The changes reported by CQ are not the cause of this failure and I may be mistaken but I suspect it may be related to one of the below changes. *Link and headline of suspected patches: * *https://gerrit.ovirt.org/#/c/90784/ <https://gerrit.ovirt.org/#/c/90784/> - network: default ovn provider client is returned by fixturehttps://gerrit.ovirt.org/#/c/90327/ <https://gerrit.ovirt.org/#/c/90327/> - backend, packing: Add default MTU for tunnelled networksLink to Job:* *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7492/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7492/>* http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7488/ *Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7492/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7492/artifact…>(Relevant) error snippet from the log: <error>* 2018-05-11 04:14:34,940-0400 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py", line 779, in _customization self._query_install_ovn() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py", line 399, in _query_install_ovn default=True File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/dialog.py", line 47, in queryBoolean default=true if default else false, File "/usr/share/otopi/plugins/otopi/dialog/human.py", line 211, in queryString value = self._readline(hidden=hidden) File "/usr/lib/python2.7/site-packages/otopi/dialog.py", line 248, in _readline raise IOError(_('End of file')) IOError: End of file 2018-05-11 04:14:34,942-0400 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Environment customization': End of file 2018-05-11 04:14:34,972-0400 DEBUG otopi.plugins.otopi.debug.debug_failure.debug_failure debug_failure._notification:100 tcp connections: id uid local foreign state pid exe 0: 0 0.0.0.0:111 0.0.0.0:0 LISTEN 1829 /usr/sbin/rpcbind 1: 29 0.0.0.0:662 0.0.0.0:0 LISTEN 1868 /usr/sbin/rpc.statd 2: 0 0.0.0.0:22 0.0.0.0:0 LISTEN 970 /usr/sbin/sshd 3: 0 192.168.201.2:3260 0.0.0.0:0 LISTEN UnknownPID UnknownEXE 4: 0 192.168.200.2:3260 0.0.0.0:0 LISTEN UnknownPID UnknownEXE 5: 0 0.0.0.0:892 0.0.0.0:0 LISTEN 1874 /usr/sbin/rpc.mountd 6: 0 0.0.0.0:2049 0.0.0.0:0 LISTEN UnknownPID UnknownEXE 7: 0 0.0.0.0:32803 0.0.0.0:0 LISTEN UnknownPID UnknownEXE 8: 0 192.168.201.2:22 192.168.201.1:33338 ESTABLISHED 5544 /usr/sbin/sshd 2018-05-11 04:14:34,973-0400 DEBUG otopi.context context.dumpEnvironment:859 ENVIRONMENT DUMP - BEGIN 2018-05-11 04:14:34,973-0400 DEBUG otopi.context context.dumpEnvironment:869 ENV BASE/error=bool:'True' 2018-05-11 04:14:34,973-0400 DEBUG otopi.context context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[(<type 'exceptions.IOError'>, IOError('End of file',), <traceback object at 0x239ab90>)]' 2018-05-11 04:14:34,974-0400 DEBUG otopi.context context.dumpEnvironment:873 ENVIRONMENT DUMP - END 2018-05-11 04:14:34,975-0400 INFO otopi.context context.runSequence:741 Stage: Clean up 2018-05-11 04:14:34,975-0400 DEBUG otopi.context context.runSequence:745 STAGE cleanup 2018-05-11 04:14:34,976-0400 DEBUG otopi.context context._executeMethod:128 Stage cleanup METHOD otopi.plugins.otopi.dialog.answer_file.Plugin._generate_answer_file 2018-05-11 04:14:34,977-0400 DEBUG otopi.context context.dumpEnvironment:859 ENVIRONMENT DUMP - BEGIN 2018-05-11 04:14:34,977-0400 DEBUG otopi.context context.dumpEnvironment:869 ENV DIALOG/answerFileContent=str:'# OTOPI answer file, generated by human dialog [environment:default] ' *</error>Thanks, Dafna*

3 3

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 10-05-2018 ] [ 001_upgrade_engine.test_initialize_engine ]
by Dafna Ron 11 May '18

11 May '18

Hi, We are failing on deploying engine (test: 001_upgrade_engine.test_initialize_engine) duet to version bump for package vdsm-jsonrpc. Can you please revert the change or add the missing package? Please note that all ovirt-engine changes are failing and there are a few. *Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/91084/ <https://gerrit.ovirt.org/#/c/91084/> - jsonrpc: version bump Link to Job:* *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7281/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7281/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7281/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7281/artifact>(Relevant) error snippet from the log: <error>* [ INFO ] Checking for an update for Setup... [ ERROR ] Yum [u'ovirt-engine-backend-4.3.0-0.0.master.20180509105818.gitf6b5283.el7.centos.noarch requires vdsm-jsonrpc-java >= 1.4.13'] [ INFO ] Yum Performing yum transaction rollback [ ERROR ] Failed to execute stage 'Environment customization': [u'ovirt-engine-backend-4.3.0-0.0.master.20180509105818.gitf6b5283.el7.centos.noarch requires vdsm-jsonrpc-java >= 1.4.13'] [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20180509074146-er3dzr.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20180509074148-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed ("FATAL Internal error (main): [u'ovirt-engine-backend-4.3.0-0.0.master.20180509105818.gitf6b5283.el7.centos.noarch requires vdsm-jsonrpc-java >= 1.4.13']",) lago.ssh: DEBUG: Command f3aaeaac on lago-upgrade-from-release-suite-master-engine errors: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/__main__.py", line 88, in main installer.execute() File "/usr/lib/python2.7/site-packages/otopi/main.py", line 157, in execute self.context.runSequence() File "/usr/lib/python2.7/site-packages/otopi/context.py", line 771, in runSequence util.raiseExceptionInformation(infos[0]) File "/usr/lib/python2.7/site-packages/otopi/util.py", line 81, in raiseExceptionInformation exec('raise info[1], None, info[2]') File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 417, in _customization ) = self._checkForProductUpdate() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 248, in _checkForProductUpdate if mpm.buildTransaction(): File "/usr/lib/python2.7/site-packages/otopi/miniyum.py", line 920, in buildTransaction raise yum.Errors.YumBaseError(msg) YumBaseError: [u'ovirt-engine-backend-4.3.0-0.0.master.20180509105818.gitf6b5283.el7.centos.noarch requires vdsm-jsonrpc-java >= 1.4.13'] *</error>*

4 11

Jupiter isn't just a planet - it's how we test things in the Engine
by Allon Mureinik 10 May '18

10 May '18

Hi all, Over the past couple of days I've merged a series of patches that upgrade the Engine's usage of JUnit to JUnit Jupiter 5.2 in order to make it easier to write new tests. Despite the patches being quite straight-forward, since Jupiter is **not** backwards compatible to JUnit 4, or even JUnit 5 Vintage, here's the short version of what you need to know: 1. You no longer use annotations from the org.junit package, but the junit.org.jupiter.api packages. @Before and @After have been replaced with @BeforeEach and AfterEach respectively, and @BeforeClass and @AfterClass have been replaced with @BeforeAll and @AfterAll. 2. Assertions now live in the org.junit.jupiter.api.Assertions class. Note that the optional message parameter is now the **last** parameter in all the assertions, not the first. Also worth noting that assertThat has been removed. More often than not, assertTrue can be used with a Supplier<Boolean>, but if you absolutely need an assertThat method, just use the one that Hamcrest provides. 3. Similarly, assumptions live in org.junit.jupiter.api.Assumptions. 4. No more runners - extending tests in JUnit Jupiter is done with Extensions. There's no longer a need for the Parameterized and Theories runners, as you can just use the built-in @ParameterizedTest annotation. Instead of the MockitoJUnitRunner we used to heavily rely on, you should now use MockitoExtension. 5. No more Rules - these too were replaced with extensions. Our custom rules were replaced with extensions, which are pretty well documented both in their javadoc and in wiki under [1] For additional information, you could take a look at the official documentation [2] Happy testing! Allon [1] https://ovirt.org/develop/dev-process/unit-testing-utilities/ [2] https://junit.org/junit5/docs/current/user-guide/

1 0

Jupiter isn't just a planet - it's how we test things in the Engine
by Allon Mureinik 10 May '18

10 May '18

Hi all, Over the past couple of days I've merged a series of patches that upgrade the Engine's usage of JUnit to JUnit Jupiter 5.2 in order to make it easier to write new tests. Despite the patches being quite straight-forward, since Jupiter is **not** backwards compatible to JUnit 4, or even JUnit 5 Vintage, here's the short version of what you need to know: 1. You no longer use annotations from the org.junit package, but the junit.org.jupiter.api packages. @Before and @After have been replaced with @BeforeEach and AfterEach respectively, and @BeforeClass and @AfterClass have been replaced with @BeforeAll and @AfterAll. 2. Assertions now live in the org.junit.jupiter.api.Assertions class. Note that the optional message parameter is now the **last** parameter in all the assertions, not the first. Also worth noting that assertThat has been removed. More often than not, assertTrue can be used with a Supplier<Boolean>, but if you absolutely need an assertThat method, just use the one that Hamcrest provides. 3. Similarly, assumptions live in org.junit.jupiter.api.Assumptions. 4. No more runners - extending tests in JUnit Jupiter is done with Extensions. There's no longer a need for the Parameterized and Theories runners, as you can just use the built-in @ParameterizedTest annotation. Instead of the MockitoJUnitRunner we used to heavily rely on, you should now use MockitoExtension. 5. No more Rules - these too were replaced with extensions. Our custom rules were replaced with extensions, which are pretty well documented both in their javadoc and in wiki under [1] For additional information, you could take a look at the official documentation [2] Happy testing! Allon [1] https://ovirt.org/develop/dev-process/unit-testing-utilities/ [2] https://junit.org/junit5/docs/current/user-guide/

1 0

CentOS 7.5.1804 is now officially available
by Sandro Bonazzola 10 May '18

10 May '18

FYI, CentOS 7.5.1804 is now officially available. See announce here: https://lists.centos.org/pipermail/centos-announce/2018-May/022829.html Users: I suggest to upgrade in order to get latest features, fixes and security fixes. Just a note for ppc64le users, there's a known bug with libguestfs requiring qemu-kvm-ma instead of qemu-kvm that may cause upgrade issues. This should be fixed in next update which should land in CentOS in ~2 weeks. If you are still on 4.1, please change your centos repos to point to http://mirror.centos.org/centos/7.4.1708/ instead of http://mirror.centos.org/centos/7. Then please update to latest 4.1 and then to oVirt 4.2 + CentOS 7.5 as soon as you can. Devel: please cross check your jenkins jobs, especially those having to do something with 4.1 since CentOS 7.5 is not supporting oVirt 4.1 anymore. See above. Infra: please schedule a mass update of oVirt infrastructure to CentOS 7.5 + oVirt 4.2.3 ASAP. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

3 5

Work-Around for Access Problem to resources.ovirt.org and jenkins.ovirt.org
by Anton Marchukov 09 May '18

09 May '18

Hello All. Please note that ovirt.org got HSTS setting enabled. The way this change was rolled was not authorised by us. The setting contains “includeSubDomains” parameter that ask browser to access all resources inside *.ovirt.org using https://. The problem is that not all resources on *.ovirt.org are https-enabled. And this will prevent you from being able to access http://resources.ovirt.org http://jenkins.ovirt.org This setting is cached in your browser and then applied with no exceptions even if you explicitly specify http:// the browser will rewrite to https and then connection to above mentioned resources will fail. The only immediate work-around for you is to clear the HSTS flag in your browser, please find the instructions for Firefox and Chrome [1]. Please note that you will get that setting back by visiting ovirt.org website until we clear it from there. We are currently working on this setting to be soften or disabled till all resources are https enabled that is also in progress. This is only related to access via the web browser. Accessing using yum or automated scripts should work fine as they usually do not observe and cache HSTS. Anton. [1] https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/

3 2

Please update your Fedora
by Sandro Bonazzola 09 May '18

09 May '18

Hi, if you're not yet on Fedora 28, please consider updating to it. On master we are aiming to support Fedora 28 and we are dismissing any older Fedora jobs in Jenkins soon. As a reminder Fedora 26 support is going to be EOL on Tuesday, May 29th, 2018. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

2 1

Fwd: [JIRA] (OVIRT-2005) jira.ovirt.org redirect doesn't work anymore, redirects instead to https://jira.ovirt.org/ovirt.apps/
by Eyal Edri 09 May '18

09 May '18

FYI, It seems jira.ovirt.org redirect doesn't work, since we don't own the jira instance ( cloud provided by Attlasian ) it might be a change done on their side. We'll investigate and check possible solutions. Until then, please use the full URL for the JIRA instance - https://ovirt-jira.atlassian.net ---------- Forwarded message ---------- From: eyal edri (oVirt JIRA) <jira(a)ovirt-jira.atlassian.net> Date: Wed, May 9, 2018 at 10:11 AM Subject: [JIRA] (OVIRT-2005) jira.ovirt.org redirect doesn't work anymore, redirects instead to https://jira.ovirt.org/ovirt.apps/ To: infra(a)ovirt.org [ https://ovirt-jira.atlassian.net/browse/OVIRT-2005?page=com.atlassian.jira.… ] eyal edri updated OVIRT-2005: Epic Link: OVIRT-403 jira.ovirt.org redirect doesn't work anymore, redirects instead to https://jira.ovirt.org/ovirt.apps/ Key: OVIRT-2005 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2005 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: eyal edri Assignee: infra Priority: High [~ederevea] any idea what could cause this? maybe Atlassian blocked us or IP was changed? cc [~ena(a)redhat.com] [~bkorren(a)redhat.com] — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100083) _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-leave(a)ovirt.org -- Eyal edri MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0

oVirt Orb 4.2.3 is now available
by Sandro Bonazzola 09 May '18

09 May '18

oVirt Orb image has been updated with oVirt 4.2.3 content[1] oVirt Orb is a project that allows anyone to easily take an oVirt for a ride, test and play with it. See oVirt Orb documentation for using it[2] [1] http://resources.ovirt.org/pub/ovirt-4.2/ovirt-orb/ [2] https://ovirt.org/documentation/ovirt-orb/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

3 5

Tracking down a vdsm memory leak
by Chris Adams 08 May '18

08 May '18

I have a problem with a memory leak in vdsm. I have a dev cluster that right now is: - two nodes - CentOS 7.4 (up to date) - oVirt 4.2.2 (installed as 3.5 and upgraded version by version) - hosted engine (no other running VM at the moment) - iSCSI storage I have a script that writes the vdsm RSS to a file every five minutes, and on the node holding the hosted engine, vdsm RSS grows around 300-1500KB every snapshot. I maintain several oVirt clusters for others, and they all seem to have this problem. The production clusters are all still on oVirt 4.1, but they all have this problem too, so I guess it is something about how I set them up? On a couple I just checked, the vdsm RSS is over 1G. Any tips on instrumenting vdsm to track this down? I am unfortunately only passingly familiar with python (I can make small changes, but not knowledgeable enough to figure this out). -- Chris Adams <cma(a)cmadams.net>

3 8