September 2016 - Devel - oVirt List Archives

[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

[VDSM] new(?) network test failure
by Nir Soffer 11 Sep '16

11 Sep '16

Seen this (new?) failure on master - please check: http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/216/console 0:59:51 ====================================================================== 10:59:51 FAIL: test_ip_info (network.netinfo_test.TestNetinfo) 10:59:51 ---------------------------------------------------------------------- 10:59:51 Traceback (most recent call last): 10:59:51 File "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testValidation.py", line 97, in wrapper 10:59:51 return f(*args, **kwargs) 10:59:51 File "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/network/netinfo_test.py", line 359, in test_ip_info 10:59:51 [IPV6_ADDR_CIDR])) 10:59:51 AssertionError: Tuples differ: ('192.0.2.2', '255.255.255.0',... != ('192.0.2.2', '255.255.255.0',... 10:59:51 10:59:51 First differing element 2: 10:59:51 ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32'] 10:59:51 ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32', '192.0.2.3/24'] 10:59:51 10:59:51 ('192.0.2.2', 10:59:51 '255.255.255.0', 10:59:51 - ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32'], 10:59:51 + ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32', '192.0.2.3/24'], 10:59:51 ? ++++++++++++++++ 10:59:51 10:59:51 ['2607:f0d0:1002:51::4/64']) 10:59:51 -------------------- >> begin captured logging << -------------------- 10:59:51 2016-09-08 10:59:40,924 DEBUG [root] (MainThread) /usr/bin/taskset --cpu-list 0-1 /sbin/ip link add name dummy_GX6CE type dummy (cwd None) 10:59:51 2016-09-08 10:59:40,944 DEBUG [root] (MainThread) SUCCESS: <err> = ''; <rc> = 0 10:59:51 2016-09-08 10:59:40,950 DEBUG [root] (MainThread) /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev dummy_GX6CE up (cwd None) 10:59:51 2016-09-08 10:59:40,968 DEBUG [root] (MainThread) SUCCESS: <err> = ''; <rc> = 0 10:59:51 2016-09-08 10:59:40,971 DEBUG [root] (MainThread) /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE 192.0.2.2/24 (cwd None) 10:59:51 2016-09-08 10:59:40,988 DEBUG [root] (MainThread) SUCCESS: <err> = ''; <rc> = 0 10:59:51 2016-09-08 10:59:40,991 DEBUG [root] (MainThread) /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE 192.0.2.3/24 (cwd None) 10:59:51 2016-09-08 10:59:41,007 DEBUG [root] (MainThread) SUCCESS: <err> = ''; <rc> = 0 10:59:51 2016-09-08 10:59:41,010 DEBUG [root] (MainThread) /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE 198.51.100.9/24 (cwd None) 10:59:51 2016-09-08 10:59:41,037 DEBUG [root] (MainThread) SUCCESS: <err> = ''; <rc> = 0 10:59:51 2016-09-08 10:59:41,040 DEBUG [root] (MainThread) /usr/bin/taskset --cpu-list 0-1 /sbin/ip -6 addr add dev dummy_GX6CE 2607:f0d0:1002:51::4/64 (cwd None) 10:59:51 2016-09-08 10:59:41,067 DEBUG [root] (MainThread) SUCCESS: <err> = ''; <rc> = 0 10:59:51 2016-09-08 10:59:41,071 DEBUG [root] (MainThread) /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE 198.51.100.11/32 (cwd None) 10:59:51 2016-09-08 10:59:41,090 DEBUG [root] (MainThread) SUCCESS: <err> = ''; <rc> = 0 10:59:51 2016-09-08 10:59:41,102 DEBUG [root] (MainThread) /usr/bin/taskset --cpu-list 0-1 /sbin/ip link del dev dummy_GX6CE (cwd None) 10:59:51 2016-09-08 10:59:41,133 DEBUG [root] (MainThread) SUCCESS: <err> = ''; <rc> = 0 10:59:51 --------------------- >> end captured logging << ---------------------

3 4

[ANN] oVirt 4.0.4 RC2 is now available
by Rafael Martins 09 Sep '16

09 Sep '16

The oVirt Project is pleased to announce the availability of the Second Release Candidate of oVirt 4.0.4 for testing, as of September 7th, 2016. This release is available now for: * Fedora 23 (tech preview) * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 (tech preview) * oVirt Next Generation Node 4.0 This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This update is the first release candidate of the fourth in a series of stabilization updates to the 4.0 series. See the release notes [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is available. [4] * A new oVirt Next Generation Node is available [4]. * A new oVirt Engine Appliance is available for Red Hat Enterprise Linux and CentOS Linux (or similar) * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.4 release highlights:http://www.ovirt.org/release/4.0.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog:http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.0.4/ [4] http://resources.ovirt.org/pub/ovirt-4.0-pre/iso/ [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Rafael Martins

2 2

Fwd: F26 System Wide Change: DNF 2.0
by Sandro Bonazzola 09 Sep '16

09 Sep '16

FYI This affects engine-setup, ovirt-hosted-engine-setup, ovirt-host-deploy and any other tool based on OTOPI in 4.2 time frame. ---------- Forwarded message ---------- From: Jan Kurik <jkurik(a)redhat.com> Date: Fri, Sep 9, 2016 at 4:49 PM Subject: F26 System Wide Change: DNF 2.0 To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>, devel-announce(a)lists.fedoraproject.org = Proposed System Wide Change: DNF 2.0 = https://fedoraproject.org/wiki/Changes/DNF-2.0 Change owner(s): * Jan Silhan <jsilhan AT redhat DOT com> * Michal Luscon <mluscon AT redhat DOT com> * Igor Gnatenko <ignatenko AT redhat DOT com> DNF rebase to version 2.0. == Detailed Description == DNF-2.0 is the next upcoming major version of DNF package manager. Unfortunately, it brings some incompatibilities with previous version of DNF (DNF-1) which were either needed to preserve compatibility with YUM CLI or where bigger redesigns were needed. A list of identified incompatible changes can be found here http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html == Scope == Proposal owners: * complete release notes * deliver DNF-2.0 stack to Rawhide Other developers: * Owners of 3rd party DNF plugins or components depending on DNF should check and adjust their packages otherwise they may not work with DNF-2.0. Release engineering: * All release engineering tools that depends on DNF should be tested against DNF-2.0. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel(a)lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- 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