[vdsm] oVirt January 2014 Updates
1. VERSIONS - oVirt 3.3.3 in last phases http://www.ovirt.org/OVirt_3.3.3_release_notes - oVirt 3.4 with another slew of features is getting into test day, beta, etc. http://red.ht/1eo9TiS 2. WORKSHOPS - Fosdem - oVirt stand wass packed as well as a virt IaaS devroom, with many oVirt talks. more details next time. - more oVirt talks in cfgmgmtcamp and infra.next this week, including: -- Hervé Leclerc How we build a cloud with CentOS, oVirt, and Cisco-UCS Wednesday 5th February in Infrastructure.Next Ghent http://bit.ly/1fjTJVC -- oVirt Node being used as a Discovery Node in The Foreman project talk at cfgmgmtcamp, february 3rd http://bit.ly/1gAnneI - oVirt Korea group meeting this Saturday in Seoul Register here http://onoffmix.com/event/23134 - Open Virtualization Workshop in Tehran (26,27 February 2014) Isfahan (5,6 March 2014) http://t.co/9PR3BxOnpd 3. USING oVirt - More details on Wind River using ovirt http://bit.ly/1i2LtLI - New Case Study: Nieuwland Geo-Informati http://www.ovirt.org/Nieuwland_case_study - oVirt Node being used as a Discovery Node in The Foreman project talk at cfgmgmtcamp, february 3rd http://bit.ly/1gAnneI 4. Users - Double the amount of emails on users mailing list- up from 800 to 1600 this month! - Karli updated how to use spice with ovirt from OS X http://www.ovirt.org/SPICE_Remote-Viewer_on_OS_X - Opaque (spice android ovirt client) v1.1.8 beta released https://plus.google.com/communities/116099119712127782216 - how to deploy windows guest agent on windows: http://bit.ly/1kr5tJo - Andrew Lau posted on working through Hosted Engine with 3.4.0 beta http://bit.ly/1eobzZw - Deep Dive into oVirt 3.3.3 by Li Jiansheng (chinese) http://slidesha.re/1eFWQ8G - Matthew Bingham posted a series of video on setting up ovirt: Install oVirt 3.3.2 http://www.youtube.com/watch?v=GWT-m-oWSjQ Optional export nfs mount for oVirt 3.3.2 http://www.youtube.com/watch?v=MLbPln5-2jE Initial webgui oVirt 3.3.2 Steps for storage http://www.youtube.com/watch?v=dL0_03ZICw4 Download and upload client iso to ISO_DOMAIN for oVirt 3.3.2 http://www.youtube.com/watch?v=pDzTHFSmvGE ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] mom RPMs for 3.4
Da: arch-boun...@ovirt.org A: Dan Kenigsberg dan...@redhat.com,Adam Litke ali...@redhat.com Cc: engine-de...@ovirt.org,arch a...@ovirt.org,VDSM Project Development vdsm-devel@lists.fedorahosted.org Data: Mon, 03 Feb 2014 08:50:12 +0100 Oggetto: Re: mom RPMs for 3.4 Il 01/02/2014 23:48, Dan Kenigsberg ha scritto: On Fri, Jan 31, 2014 at 04:56:12PM -0500, Adam Litke wrote: On 31/01/14 08:36 +0100, Sandro Bonazzola wrote: Il 30/01/2014 19:30, Adam Litke ha scritto: On 30/01/14 18:13 +, Dan Kenigsberg wrote: On Thu, Jan 30, 2014 at 11:49:42AM -0500, Adam Litke wrote: Hi Sandro, After updating the MOM project's build system, I have used jenkins to produce a set of RPMs that I would like to tag into the oVirt 3.4 release. Please see the jenkins job [1] for the relevant artifacts for EL6[2], F19[3], and F20[4]. Dan, should I submit a patch to vdsm to make it require mom = 0.4.0? I want to be careful to not break people's environments this late in the 3.4 release cycle. What is the best way to minimize that damage? Hey, we're during beta. I prefer making this requirement explicit now over having users with supervdsmd.log retate due to log spam. In that case, Sandro, can you let me know when those RPMs hit the ovirt repos (for master and 3.4) and then I will submit a patch to vdsm to require the new version. mom 0.4.0 has been built in last night nightly job [1] and published to nightly by publisher job [2] so it's already available on nightly [3] For 3.4.0, it has been planned [4] a beta 2 release on 2014-02-06 so we'll include your builds in that release. I presume the scripting for 3.4 release rpms will produce a version without the git-rev based suffix: ie. mom-0.4.0-1.rpm? I need to figure out how to handle a problem that might be a bit unique to mom. MOM is used by non-oVirt users who install it from the main Fedora repository. I think it's fine that we are producing our own rpms in oVirt (that may have additional patches applied and may resync to upstream mom code more frequently than would be desired for the main Fedora repository). Given this, I think it makes sense to tag the oVirt RPMs with a special version suffix to indicate that these are oVirt produced and not upstream Fedora. For example: The next Fedora update will be mom-0.4.0-1.f20.rpm. The next oVirt update will be mom-0.4.0-1ovirt.f20.rpm. Is this the best practice for accomplishing my goals? One other thing I'd like to have the option of doing is to make vdsm depend on an ovirt distribution of mom so that the upstream Fedora version will not satisfy the dependency for vdsm. What is the motivation for this? You would not like to bother Fedora users with updates that are required only for oVirt? Vdsm itself is built, signed, and distributed via Fedora. It is also copied into the ovirt repo, for completeness sake. Could MoM do the same? IMHO, if we're distributing mom and vdsm rpms through Fedora yum repository we should not duplicate it on ovirt yum repository. Fedora package is signed and will differ from the one we're shipping within ovirt repo (which is unsigned) We should provide on resource.ovirt.org only packages not available on downstream repositories (like nightly builds).why you can't sign your rpms???on ovirt web page http://www.ovirt.org/Home you can change:Enhanced security: SELinux and Mandatory Access Control for VMs and hypervisor with:Enhanced security: SELinux and Mandatory Access Control for VMs and hypervisor (but not signed rpms)best regardsa Dan. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Migration failed (previous migrations succeded)
Where? in the file itself? Mine just contains this: [addresses] management_port = 54321 [vars] ssl = true This is a CentOS minimal with vdsm installed on top. versions are: rpm -qa | grep vdsm vdsm-4.12.1-4.el6.x86_64 vdsm-cli-4.12.1-4.el6.noarch vdsm-python-4.12.1-4.el6.x86_64 vdsm-python-cpopen-4.12.1-4.el6.x86_64 vdsm-xmlrpc-4.12.1-4.el6.noarch Is this information maybe just available in the node images? Did I hit a bug? Am 03.02.2014 13:43, schrieb Michal Skrivanek: the vdsm.conf has a description for each parameter -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Migration failed (previous migrations succeded)
On Feb 4, 2014, at 09:40 , Sven Kieske s.kie...@mittwald.de wrote: Where? in the file itself? maybe in sample file only...usr/share/doc/vdsm-*/vdsm.conf.sample Thanks, michal Mine just contains this: [addresses] management_port = 54321 [vars] ssl = true This is a CentOS minimal with vdsm installed on top. versions are: rpm -qa | grep vdsm vdsm-4.12.1-4.el6.x86_64 vdsm-cli-4.12.1-4.el6.noarch vdsm-python-4.12.1-4.el6.x86_64 vdsm-python-cpopen-4.12.1-4.el6.x86_64 vdsm-xmlrpc-4.12.1-4.el6.noarch Is this information maybe just available in the node images? Did I hit a bug? Am 03.02.2014 13:43, schrieb Michal Skrivanek: the vdsm.conf has a description for each parameter -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] suggested patch for python-pthreading
according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock in each coredump we saw few threads stuck with the bt: #16 0x7fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=value optimized out) at Python/ceval.c:3663 #17 0x7fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428 #18 0x7fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301 #19 0x7fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override. we suggest the following commit: From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001 From: Yaniv Bronhaim ybron...@redhat.com Date: Mon, 3 Feb 2014 19:24:30 +0200 Subject: [PATCH] Mocking thread.allocate_lock with Lock imp Signed-off-by: Yaniv Bronhaim ybron...@redhat.com --- pthreading.py | 4 1 file changed, 4 insertions(+) diff --git a/pthreading.py b/pthreading.py index 916ca7f..96df42c 100644 --- a/pthreading.py +++ b/pthreading.py @@ -132,6 +132,10 @@ def monkey_patch(): Thus, Queue and SocketServer can easily enjoy them. +import thread + +thread.allocate_lock = Lock + import threading threading.Condition = Condition -- 1.8.3.1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749 Thanks, Yaniv Bronhaim. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggested patch for python-pthreading
- Original Message - From: Yaniv Bronheim ybron...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:04:37 AM Subject: [vdsm] suggested patch for python-pthreading according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock in each coredump we saw few threads stuck with the bt: #16 0x7fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=value optimized out) at Python/ceval.c:3663 #17 0x7fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428 #18 0x7fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301 #19 0x7fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override. we suggest the following commit: From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001 From: Yaniv Bronhaim ybron...@redhat.com Date: Mon, 3 Feb 2014 19:24:30 +0200 Subject: [PATCH] Mocking thread.allocate_lock with Lock imp Signed-off-by: Yaniv Bronhaim ybron...@redhat.com --- pthreading.py | 4 1 file changed, 4 insertions(+) diff --git a/pthreading.py b/pthreading.py index 916ca7f..96df42c 100644 --- a/pthreading.py +++ b/pthreading.py @@ -132,6 +132,10 @@ def monkey_patch(): Thus, Queue and SocketServer can easily enjoy them. +import thread + +thread.allocate_lock = Lock + import threading threading.Condition = Condition -- 1.8.3.1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749 Replacing allocate_lock in thread is correct. However, since threading copies thread.allocate_lock, and you don't control import order, you have to monkeypatch threading.allocate_lock as well. The full should be: import thread thread.allocate_lock = Lock import threading threading.allocate_lock = Lock threading.Lock = Lock Nir ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggested patch for python-pthreading
- Original Message - From: Nir Soffer nsof...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:39:56 AM Subject: Re: [vdsm] suggested patch for python-pthreading - Original Message - From: Yaniv Bronheim ybron...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:04:37 AM Subject: [vdsm] suggested patch for python-pthreading according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock in each coredump we saw few threads stuck with the bt: #16 0x7fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=value optimized out) at Python/ceval.c:3663 #17 0x7fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428 #18 0x7fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301 #19 0x7fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override. we suggest the following commit: From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001 From: Yaniv Bronhaim ybron...@redhat.com Date: Mon, 3 Feb 2014 19:24:30 +0200 Subject: [PATCH] Mocking thread.allocate_lock with Lock imp Signed-off-by: Yaniv Bronhaim ybron...@redhat.com --- pthreading.py | 4 1 file changed, 4 insertions(+) diff --git a/pthreading.py b/pthreading.py index 916ca7f..96df42c 100644 --- a/pthreading.py +++ b/pthreading.py @@ -132,6 +132,10 @@ def monkey_patch(): Thus, Queue and SocketServer can easily enjoy them. +import thread + +thread.allocate_lock = Lock + import threading threading.Condition = Condition -- 1.8.3.1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749 Replacing allocate_lock in thread is correct. However, since threading copies thread.allocate_lock, and you don't control import order, you have to monkeypatch threading.allocate_lock as well. The full should be: import thread thread.allocate_lock = Lock import threading threading.allocate_lock = Lock threading.Lock = Lock Nir thanks Nir for the reply and review I guess you meant threading._allocate_lock, but we monkey patch it in an order so we do control the import order.. not sure its necessary ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggested patch for python-pthreading
- Original Message - From: Yaniv Bronheim ybron...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:53:52 AM Subject: Re: [vdsm] suggested patch for python-pthreading - Original Message - From: Nir Soffer nsof...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:39:56 AM Subject: Re: [vdsm] suggested patch for python-pthreading - Original Message - From: Yaniv Bronheim ybron...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:04:37 AM Subject: [vdsm] suggested patch for python-pthreading according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock in each coredump we saw few threads stuck with the bt: #16 0x7fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=value optimized out) at Python/ceval.c:3663 #17 0x7fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428 #18 0x7fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301 #19 0x7fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override. we suggest the following commit: From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001 From: Yaniv Bronhaim ybron...@redhat.com Date: Mon, 3 Feb 2014 19:24:30 +0200 Subject: [PATCH] Mocking thread.allocate_lock with Lock imp Signed-off-by: Yaniv Bronhaim ybron...@redhat.com --- pthreading.py | 4 1 file changed, 4 insertions(+) diff --git a/pthreading.py b/pthreading.py index 916ca7f..96df42c 100644 --- a/pthreading.py +++ b/pthreading.py @@ -132,6 +132,10 @@ def monkey_patch(): Thus, Queue and SocketServer can easily enjoy them. +import thread + +thread.allocate_lock = Lock + import threading threading.Condition = Condition -- 1.8.3.1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749 Replacing allocate_lock in thread is correct. However, since threading copies thread.allocate_lock, and you don't control import order, you have to monkeypatch threading.allocate_lock as well. The full should be: import thread thread.allocate_lock = Lock import threading threading.allocate_lock = Lock threading.Lock = Lock Nir thanks Nir for the reply and review I guess you meant threading._allocate_lock, but we monkey patch it in an order so we do control the import order.. not sure its necessary Correct, threading._allocate_lock. And we also have to patch threading._active_limbo_lock. We don't control the user import order - If I import threading before pthreading, both threading._allocate_lock and threading._active_limbo_lock are using the incorrect lock. Since many library modules import threading, it is impossible to require any import order. The safest way would be to patch all places that may use the original thread.allocate_lock. Nir ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggested patch for python-pthreading
On Tue, Feb 04, 2014 at 04:04:37AM -0500, Yaniv Bronheim wrote: according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock in each coredump we saw few threads stuck with the bt: #16 0x7fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=value optimized out) at Python/ceval.c:3663 #17 0x7fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428 #18 0x7fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301 #19 0x7fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override. we suggest the following commit: From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001 From: Yaniv Bronhaim ybron...@redhat.com Date: Mon, 3 Feb 2014 19:24:30 +0200 Subject: [PATCH] Mocking thread.allocate_lock with Lock imp Signed-off-by: Yaniv Bronhaim ybron...@redhat.com --- pthreading.py | 4 1 file changed, 4 insertions(+) diff --git a/pthreading.py b/pthreading.py index 916ca7f..96df42c 100644 --- a/pthreading.py +++ b/pthreading.py @@ -132,6 +132,10 @@ def monkey_patch(): Thus, Queue and SocketServer can easily enjoy them. +import thread + +thread.allocate_lock = Lock + import threading threading.Condition = Condition -- 1.8.3.1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749 It makes sense to use pthreading.Lock for thread.allocate_lock instead of the standard threading.Lock CPU hog. However, I do not understand its relevance to the deadlock sited above: pthreading.Lock fixes performance issues, but not correctness issues, of threading.Lock. Would you explain, in the commit message of the pthreading patch, why you believe that the implementation of thread.allocate_lock() is buggy? Do you know if the bug is fixed in Python 3? Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] [QE] oVirt 3.4.0 beta status
Hi, oVirt 3.4.0 beta has been released and is actually on QA. We're going to tart composing oVirt 3.4.0 beta2 this Thursday 2014-02-06 09:00 UTC from 3.4 branches. This build will be used for a second Test Day scheduled for 2014-02-11. The bug tracker [1] shows the following bugs blocking the release: Whiteboard Bug ID Status Summary gluster 1038988 POSTGluster brick sync does not work when host has multiple interfaces gluster 1059606 POSTErrors in rebalance and remove-brick status and sync integration 1054080 POSTgracefully warn about unsupported upgrade from legacy releases integration 1058018 POSTupgrade from 3.3 overwrites exports with acl None There are still 393 bugs [2] targeted to 3.4.0. Excluding node and documentation bugs we still have 238 bugs [3] targeted to 3.4.0. Please review them as soon as possible. Maintainers: - Please remember to rebuild your packages before 2014-02-06 09:00 UTC if you want them to be included in 3.4.0 beta. - Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed. - Please provide ETA on blockers bugs - Please update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] - Please update http://www.ovirt.org/OVirt_3.4_TestDay before 2014-02-11 For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug. Please also be prepared for upcoming oVirt 3.4.0 Test Day on 2014-02-11! Thanks to all people already testing 3.4.0 beta! [1] https://bugzilla.redhat.com/1024889 [2] http://red.ht/1eIRZXM [3] http://red.ht/1auBU3r [4] http://www.ovirt.org/OVirt_3.4.0_release_notes -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] [QE] oVirt 3.4.0 beta status
On Tue, Feb 4, 2014 at 1:03 PM, Sandro Bonazzola wrote: Hi, oVirt 3.4.0 beta has been released and is actually on QA. We're going to tart composing oVirt 3.4.0 beta2 this Thursday 2014-02-06 09:00 UTC from 3.4 branches. This build will be used for a second Test Day scheduled for 2014-02-11. Is beta2 expected to be available to run on Fedora 20, engine and hosts? Thanks, Gianluca ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggested patch for python-pthreading
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Saggi Mizrahi smizr...@redhat.com Sent: Tuesday, February 4, 2014 12:20:52 PM Subject: Re: suggested patch for python-pthreading On Tue, Feb 04, 2014 at 04:04:37AM -0500, Yaniv Bronheim wrote: according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock in each coredump we saw few threads stuck with the bt: #16 0x7fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=value optimized out) at Python/ceval.c:3663 #17 0x7fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428 #18 0x7fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301 #19 0x7fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override. we suggest the following commit: From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001 From: Yaniv Bronhaim ybron...@redhat.com Date: Mon, 3 Feb 2014 19:24:30 +0200 Subject: [PATCH] Mocking thread.allocate_lock with Lock imp Signed-off-by: Yaniv Bronhaim ybron...@redhat.com --- pthreading.py | 4 1 file changed, 4 insertions(+) diff --git a/pthreading.py b/pthreading.py index 916ca7f..96df42c 100644 --- a/pthreading.py +++ b/pthreading.py @@ -132,6 +132,10 @@ def monkey_patch(): Thus, Queue and SocketServer can easily enjoy them. +import thread + +thread.allocate_lock = Lock + import threading threading.Condition = Condition -- 1.8.3.1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749 It makes sense to use pthreading.Lock for thread.allocate_lock instead of the standard threading.Lock CPU hog. However, I do not understand its relevance to the deadlock sited above: pthreading.Lock fixes performance issues, but not correctness issues, of threading.Lock. Would you explain, in the commit message of the pthreading patch, why you believe that the implementation of thread.allocate_lock() is buggy? Do you know if the bug is fixed in Python 3? Regards, Dan. We actually don't have concrete proof as we can't reproduce the bug so we can't test this. We are shooting in the dark hoping something hits. We assume it's there since all of our cordumps have a thread stuck acquiring the limbo lock. Since mixing lock implementations is probably a bad idea we assume that overriding this a thing we should do anyway we thought we'll give it a go. If VDSM gets stuck again we will have another coredump that we could compare to the others. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] [QE] oVirt 3.4.0 beta status
Il 04/02/2014 13:30, Gianluca Cecchi ha scritto: On Tue, Feb 4, 2014 at 1:03 PM, Sandro Bonazzola wrote: Hi, oVirt 3.4.0 beta has been released and is actually on QA. We're going to tart composing oVirt 3.4.0 beta2 this Thursday 2014-02-06 09:00 UTC from 3.4 branches. This build will be used for a second Test Day scheduled for 2014-02-11. Is beta2 expected to be available to run on Fedora 20, engine and hosts? I don't think so. I've opened a tracker for F20 support related issues here: https://bugzilla.redhat.com/show_bug.cgi?id=1060198 Thanks, Gianluca -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggested patch for python-pthreading
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 3:51:02 PM Subject: Re: [vdsm] suggested patch for python-pthreading On Tue, Feb 04, 2014 at 05:14:51AM -0500, Nir Soffer wrote: - Original Message - From: Yaniv Bronheim ybron...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:53:52 AM Subject: Re: [vdsm] suggested patch for python-pthreading - Original Message - From: Nir Soffer nsof...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:39:56 AM Subject: Re: [vdsm] suggested patch for python-pthreading - Original Message - From: Yaniv Bronheim ybron...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 4, 2014 11:04:37 AM Subject: [vdsm] suggested patch for python-pthreading according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock in each coredump we saw few threads stuck with the bt: #16 0x7fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=value optimized out) at Python/ceval.c:3663 #17 0x7fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428 #18 0x7fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301 #19 0x7fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override. we suggest the following commit: From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001 From: Yaniv Bronhaim ybron...@redhat.com Date: Mon, 3 Feb 2014 19:24:30 +0200 Subject: [PATCH] Mocking thread.allocate_lock with Lock imp Signed-off-by: Yaniv Bronhaim ybron...@redhat.com --- pthreading.py | 4 1 file changed, 4 insertions(+) diff --git a/pthreading.py b/pthreading.py index 916ca7f..96df42c 100644 --- a/pthreading.py +++ b/pthreading.py @@ -132,6 +132,10 @@ def monkey_patch(): Thus, Queue and SocketServer can easily enjoy them. +import thread + +thread.allocate_lock = Lock + import threading threading.Condition = Condition -- 1.8.3.1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749 Replacing allocate_lock in thread is correct. However, since threading copies thread.allocate_lock, and you don't control import order, you have to monkeypatch threading.allocate_lock as well. The full should be: import thread thread.allocate_lock = Lock import threading threading.allocate_lock = Lock threading.Lock = Lock Nir thanks Nir for the reply and review I guess you meant threading._allocate_lock, but we monkey patch it in an order so we do control the import order.. not sure its necessary Correct, threading._allocate_lock. And we also have to patch threading._active_limbo_lock. We don't control the user import order - If I import threading before pthreading, both threading._allocate_lock and threading._active_limbo_lock are using the incorrect lock. Since many library modules import threading, it is impossible to require any import order. The safest way would be to patch all places that may use the original thread.allocate_lock. The safest way would be to say loud and clear: the user must call pthreading.monkey_patch() on the begining of his main module, before threading is imported and most certainly before it is ever used. If we give the impression that doing anything else is fine, and we can end up replacing _active_limbo_lock while there's an entity (such as a _MainThread object) depending on its uniqueness. Then we should find a way to assert that the user did not import threading yet, otherwise our requirement is not very useful. If you import threading or another module that import threading, importing pthreading should raise something like: You must import pthreading before threading is imported Nir ___ vdsm-devel mailing list
Re: [vdsm] [Engine-devel] New gerrit flags behavior
+1. thanks great, and will save also from people to use 'rebase' and away to avoid from jenkins -1 verify by mistake :) eyal. - Original Message - From: David Caro dcaro...@redhat.com To: vdsm-devel@lists.fedorahosted.org, engine-devel engine-de...@ovirt.org Sent: Wednesday, January 29, 2014 2:49:31 PM Subject: [Engine-devel] New gerrit flags behavior Hi everyone! With the latest gerrit upgrade it has become easier to add the propagation of the Code Review and Verified flags when doing a trivial rebase or when no code was changed, so I've enabled those features for all the projects! The change should become effective right away, so let me know if you have any issues. Enjoy! -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
