Integrating oVirt and Gluster geo-replication to provide a DR solution
by Sahina Bose
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
8 years, 3 months
Alternatives to automatically move bugs to MODIFIED
by Yedidyah Bar David
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 years, 3 months
[ACTION REQUIRED] oVirt 4.0.4 RC3 build starting
by Sandro Bonazzola
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>
8 years, 3 months
[VDSM] Test failure test_reject_concurrency(True) (protocoldetectorTests.AcceptorTests)
by Nir Soffer
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 << ---------------------
8 years, 3 months
test - test_detect_slow_client failing
by Edward Haas
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
8 years, 3 months
[VDSM] new(?) network test failure
by Nir Soffer
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 << ---------------------
8 years, 3 months
Fwd: F26 System Wide Change: DNF 2.0
by Sandro Bonazzola
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>
8 years, 3 months
