- Devel - oVirt List Archives

[ACTION REQUIKRED] vdsm check merged for 4.0 failing on Lago repository sync
by Sandro Bonazzola 15 Sep '16

15 Sep '16

http://jenkins.ovirt.org/job/vdsm_4.0_check-merged-fc23-x86_64/146/console Please either fix lago to be more reliable when syncing repos or configure vdsm tests to use the right repos. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>

2 2

[VDSM] build-artifacts failing on master
by Nir Soffer 15 Sep '16

15 Sep '16

The build-artifacts job is failing on master now with this error: 19:09:23 Error: NOSE is too old, please install NOSE 1.3.7 or later 19:09:23 make[1]: *** [tests] Error 1 19:09:23 make[1]: Leaving directory `/home/jenkins/workspace/vdsm_master_build-artifacts-el7-x86_64/vdsm/rpmbuild/BUILD/vdsm-4.18.999' 19:09:23 error: Bad exit status from /var/tmp/rpm-tmp.LQXOfm (%check) 19:09:23 19:09:23 19:09:23 RPM build errors: 19:09:23 Bad exit status from /var/tmp/rpm-tmp.LQXOfm (%check) Looks like this patch is the cause: commit 4e729ddd2b243d0953e2de5d31c42fc59859bf23 Author: Edward Haas <edwardh(a)redhat.com> Date: Sun Sep 11 14:10:01 2016 +0300 build tests: Require NOSE 1.3.7 and up for running tests On RHEL7/Centos7 the provided NOSE version is 1.3.0. CI runs the tests with 1.3.7. To be consistent and avoid different behaviours, assure that the tests are running with a minimum nose version of 1.3.7. Specifically, between 1.3.0 and 1.3.7 a bug has been resolved regarding test labeling and its support with test class inheritance. Change-Id: If79d8624cee1c14a21840e4a08000fc33abb58e5 Signed-off-by: Edward Haas <edwardh(a)redhat.com> Reviewed-on: https://gerrit.ovirt.org/63638 Continuous-Integration: Jenkins CI Reviewed-by: Petr Horáček <phoracek(a)redhat.com> Reviewed-by: Irit Goihman <igoihman(a)redhat.com> Reviewed-by: Yaniv Bronhaim <ybronhei(a)redhat.com> Reviewed-by: Piotr Kliczewski <piotr.kliczewski(a)gmail.com> I did not check the details, but it seems we need to revert this patch. Please check and fix. Cheers, Nir

5 10

[ACTION REQUIRED] VDSM master builf failing on NOSE version check
by Sandro Bonazzola 15 Sep '16

15 Sep '16

*http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-el7-x86_64/836/console <http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-el7-x86_64/836/con…>* *00:05:37.816* make[1]: Entering directory `/home/jenkins/workspace/vdsm_master_build-artifacts-el7-x86_64/vdsm/rpmbuild/BUILD/vdsm-4.18.999'*00:05:37.817* Makefile:980: warning: overriding recipe for target `check-recursive'*00:05:37.818* Makefile:516: warning: ignoring old recipe for target `check-recursive'*00:05:38.119* Error: NOSE is too old, please install NOSE 1.3.7 or later*00:05:38.119* make[1]: *** [tests] Error 1 Is a newer version of nose really needed? If no: please require a version of nose which is available. If yes: we can consider shipping nose in CentOS Virt SIG repos since it's available for OpenStack repos: http://cbs.centos.org/koji/buildinfo?buildID=10186 Please let me know. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>

2 4

[ACTION REQUIRED] OpenVSwitch configuration changes
by Sandro Bonazzola 14 Sep '16

14 Sep '16

Hi, we received a patch to ovirt-host-deploy https://gerrit.ovirt.org/63707 related to a change in OpenVSwitch configuration between Red Hat OpenStack Platform 7 or older and Red Hat OpenStack Platform 8 or newer. - We need to ensure to catch these changes in our testing - We need to ensure oVirt host deploy still works with Red Hat OpenStack Platform 8 or newer. Dan, can you or someone in network team please review the patch? Thanks again Tony for the patch. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>

5 10

Integrating oVirt and Gluster geo-replication to provide a DR solution
by Sahina Bose 14 Sep '16

14 Sep '16

Hi all, Though there are many solutions that integrate with oVirt to provide disaster recovery for the guest images, these solutions either rely on backup agents running on guests or third party software and are complicated to setup Since oVirt already integrates with glusterfs, we can leverage gluster's geo-replication feature to mirror contents to a remote/secondary site periodically for disaster recovery, without the need for additional software Please review the PR[1] for the feature page outlining the solution and integration in oVirt. Comments and feedback welcome. [1] https://github.com/oVirt/ovirt-site/pull/453 thanks, sahina

1 0

Alternatives to automatically move bugs to MODIFIED
by Yedidyah Bar David 14 Sep '16

14 Sep '16

Hi all, We currently have a bot that automatically moves bugs from POST to MODIFIED if all linked patches on gerrit are merged. It happened to me personally several times that this was a wrong thing to do, either because a new patch was still needed but not pushed yet, or because an existing patch should have been back-ported to another branch and wasn't yet. Since I usually pay more attention to my bug in POST, I sometimes missed this and handled the missing patches (backports, usually) later than I could if left on POST. I have a feeling I am not the only one. So I suggest to stop doing this. I can think of several alternatives: 1. Do nothing. I think that's reasonable - I think most people pay more attention to POST bugs anyway. 2. Set needinfo on bug owner. 3. Send some alert email to relevant people (bug owner, existing patches owners, perhaps others - e.g. reviewers of existing patches, perhaps those that actually reviewed, etc.). Need to think how to make it not too annoying for others but still effective also if owner is on long PTO or something like that. New flag doesn't have to be very specific - can be called something like 'attention needed' or something like that. 4. Add a new flag for that and set it. This will allow easier filtering/reporting. What do you think? -- Didi

8 17

CentOS Virt SIG - aarch 64 and ppc64le support
by Sandro Bonazzola 14 Sep '16

14 Sep '16

Hi, within CentOS Virt SIG interest in having ppc64le and aarch64 as supported architecture in oVirt has raised. Packages from oVirt 4.0.2 has been built for both architectures for hypervisor host side. You can find the rpms in the cbs repositories waiting to be signed and published to mirrors here: - QEMU and deps: https://cbs.centos.org/repos/virt7-kvm-common-release/ - oVirt Common deps: https://cbs.centos.org/repos/virt7-ovirt-common-release/ - oVirt 4.0 specific packages: https://cbs.centos.org/repos/virt7-ovirt-40-release/ While I'm pretty sure ppc64le will work out of the box I think we're missing something on engine side in order to fully support aarch64. Michal, Francesco, can you open relevant BZs in order to get aarch64 fully supported? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 4

[ACTION REQUIRED] oVirt 4.0.4 RC3 build starting
by Sandro Bonazzola 14 Sep '16

14 Sep '16

Fyi oVirt products maintainers, An oVirt build for an official release is going to start right now. If you're a maintainer for any of the projects included in oVirt distribution and you have changes in your package ready to be released please: - bump version and release to be GA ready - tag your release within git (implies a GitHub Release to be automatically created) - build your packages within jenkins / koji / copr / whatever - verify all bugs on MODIFIED have target release and target milestone set. - add your builds to releng-tools/releases/ovirt-4.0.4_rc3.conf withini releng-tools project -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>

1 0

[VDSM] Test failure test_reject_concurrency(True) (protocoldetectorTests.AcceptorTests)
by Nir Soffer 12 Sep '16

12 Sep '16

test_reject_concurrency(True) (protocoldetectorTests.AcceptorTests) fails once every few month. Looks like a real issue in the actual code, doing double close. This is a known issue in asyncore that we already fixed in few places. Nir ---- 11:26:48 ====================================================================== 11:26:48 ERROR: test_reject_concurrency(True) (protocoldetectorTests.AcceptorTests) 11:26:48 ---------------------------------------------------------------------- 11:26:48 Traceback (most recent call last): 11:26:48 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/protocoldetectorTests.py", line 113, in tearDown 11:26:48 self.acceptor.stop() 11:26:48 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/protocoldetector.py", line 211, in stop 11:26:48 self._acceptor.close() 11:26:48 File "/usr/lib64/python2.7/asyncore.py", line 407, in close 11:26:48 self.del_channel() 11:26:48 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/yajsonrpc/betterAsyncore.py", line 137, in del_channel 11:26:48 asyncore.dispatcher.del_channel(self, map) 11:26:48 File "/usr/lib64/python2.7/asyncore.py", line 292, in del_channel 11:26:48 del map[fd] 11:26:48 KeyError: 63 11:26:48 -------------------- >> begin captured logging << -------------------- 11:26:48 2016-09-11 11:24:27,399 INFO [vds.MultiProtocolAcceptor] (MainThread) Listening at 127.0.0.1:46615 11:26:48 2016-09-11 11:24:27,399 DEBUG [vds.MultiProtocolAcceptor] (MainThread) Adding detector <protocoldetectorTests.Echo object at 0x7f03ee0b01d0> 11:26:48 2016-09-11 11:24:27,399 DEBUG [vds.MultiProtocolAcceptor] (MainThread) Adding detector <protocoldetectorTests.Uppercase object at 0x7f03ee0b0c50> 11:26:48 2016-09-11 11:24:27,402 INFO [ProtocolDetector.AcceptorImpl] (Thread-191) Accepting connection from 127.0.0.1:38136 11:26:48 2016-09-11 11:24:27,407 INFO [ProtocolDetector.AcceptorImpl] (Thread-191) Accepting connection from 127.0.0.1:38138 11:26:48 2016-09-11 11:24:27,411 INFO [ProtocolDetector.AcceptorImpl] (Thread-191) Accepting connection from 127.0.0.1:38140 11:26:48 2016-09-11 11:24:27,415 INFO [ProtocolDetector.AcceptorImpl] (Thread-191) Accepting connection from 127.0.0.1:38142 11:26:48 2016-09-11 11:24:27,416 DEBUG [ProtocolDetector.Detector] (Thread-191) Using required_size=9 11:26:48 2016-09-11 11:24:27,416 WARNING [vds.dispatcher] (Thread-191) unhandled write event 11:26:48 2016-09-11 11:24:27,420 INFO [ProtocolDetector.AcceptorImpl] (Thread-191) Accepting connection from 127.0.0.1:38144 11:26:48 2016-09-11 11:24:27,421 WARNING [ProtocolDetector.Detector] (Thread-191) Unrecognized protocol: 'no such p' 11:26:48 2016-09-11 11:24:27,427 DEBUG [ProtocolDetector.Detector] (Thread-191) Using required_size=9 11:26:48 2016-09-11 11:24:27,427 WARNING [vds.dispatcher] (Thread-191) unhandled write event 11:26:48 2016-09-11 11:24:27,428 DEBUG [ProtocolDetector.Detector] (Thread-191) Using required_size=9 11:26:48 2016-09-11 11:24:27,428 WARNING [vds.dispatcher] (Thread-191) unhandled write event 11:26:48 2016-09-11 11:24:27,429 WARNING [ProtocolDetector.Detector] (Thread-191) Unrecognized protocol: 'no such p' 11:26:48 2016-09-11 11:24:27,430 WARNING [ProtocolDetector.Detector] (Thread-191) Unrecognized protocol: 'no such p' 11:26:48 2016-09-11 11:24:27,430 DEBUG [ProtocolDetector.Detector] (Thread-191) Using required_size=9 11:26:48 2016-09-11 11:24:27,431 WARNING [ProtocolDetector.Detector] (Thread-191) Unrecognized protocol: 'no such p' 11:26:48 2016-09-11 11:24:27,433 DEBUG [ProtocolDetector.Detector] (Thread-191) Using required_size=9 11:26:48 2016-09-11 11:24:27,433 WARNING [ProtocolDetector.Detector] (Thread-191) Unrecognized protocol: 'no such p' 11:26:48 2016-09-11 11:24:27,434 DEBUG [vds.MultiProtocolAcceptor] (MainThread) Stopping Acceptor 11:26:48 --------------------- >> end captured logging << ---------------------

3 2

test - test_detect_slow_client failing
by Edward Haas 11 Sep '16

11 Sep '16

Looks like another failing test on CI. *20:01:00* ERROR: test_detect_slow_client(False) (protocoldetectorTests.AcceptorTests)*20:01:00* ----------------------------------------------------------------------*20:01:00* Traceback (most recent call last):*20:01:00* File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/protocoldetectorTests.py", line 113, in tearDown*20:01:00* self.acceptor.stop()*20:01:00* File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/protocoldetector.py", line 211, in stop*20:01:00* self._acceptor.close()*20:01:00* File "/usr/lib64/python2.7/asyncore.py", line 407, in close*20:01:00* self.del_channel()*20:01:00* File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/yajsonrpc/betterAsyncore.py", line 137, in del_channel*20:01:00* asyncore.dispatcher.del_channel(self, map)*20:01:00* File "/usr/lib64/python2.7/asyncore.py", line 292, in del_channel*20:01:00* del map[fd]*20:01:00* KeyError: 63

1 1