Re: [ovirt-devel] Maintenance on the Mailing-Lists

2016-05-25 Thread Sandro Bonazzola
On Thu, May 26, 2016 at 8:26 AM, Marc Dequènes (Duck) wrote: > Quack, > > I'm working in the OSAS team and arrived recently. Yoroshiku onegai > shimasu. > > With the oVirt infra team we're working on the Mailing-Lists. In the > past there was SPF problems leading to mails being classified as SPAM

[ovirt-devel] Maintenance on the Mailing-Lists

2016-05-25 Thread Duck
Quack, I'm working in the OSAS team and arrived recently. Yoroshiku onegai shimasu. With the oVirt infra team we're working on the Mailing-Lists. In the past there was SPF problems leading to mails being classified as SPAM, especially affecting GMail users. A workaround was made, but it's not nic

Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine

2016-05-25 Thread Hayley Swimelar
On 05/25/2016 02:00 AM, Martin Sivak wrote: Hi, I do not remember exacly, but you might check the source code of hosted engine's VdsmBackend where we do that too. https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-ha.git;a=blob;f=ovirt_hosted_engine_ha/lib/storage_backends.py;h=f2fbdc43d0e

[ovirt-devel] mount test failure

2016-05-25 Thread Piotr Kliczewski
I noticed build failure [1] with: 11:03:56 == 11:03:56 ERROR: testLoopMount (mountTests.MountTests) 11:03:56 -- 11:03:56 Traceback (most recent call last): 11:03:

Re: [ovirt-devel] FD leak while initializing vdsm

2016-05-25 Thread Martin Sivak
For example all the SocketServer or xmlrpclib >> abstractions close the sockets automatically. > > $ grep __del__ /usr/lib64/python2.7/SocketServer.py > $ grep __del__ /usr/lib64/python2.7/xmlrpclib.py > $ grep __del__ /usr/lib64/python2.7/SimpleXMLRPCServer.py I did not say they are using __del_

Re: [ovirt-devel] FD leak while initializing vdsm

2016-05-25 Thread Nir Soffer
On Wed, May 25, 2016 at 12:18 PM, Martin Sivak wrote: >> but it should >> not try to implement __del__ - we had lot of trouble with such code in vdsm. > > Del is perfectly fine if done properly. Python objects should really > clean after themselves. It is common to abstract the user from the low >

[ovirt-devel] [ANN] oVirt 3.6.7 First Release Candidate is now available for testing

2016-05-25 Thread Sandro Bonazzola
The oVirt Project is pleased to announce the availability of the First Release Candidate of oVirt 3.6.7 for testing, as of May 25th, 2016 This release is available now for: * Fedora 22 * Red Hat Enterprise Linux 6.7 or later * CentOS Linux (or similar) 6.7 or later * Red Hat Enterprise Linux 7.2

Re: [ovirt-devel] [ATTN] oVirt Engine 4.0 stable branch was created

2016-05-25 Thread Eyal Edri
Adding infra - please open eyes on any failures on CI, As usual, we should expect some noise and load on CI as it happens usually when we add a new branch. e. On Wed, May 25, 2016 at 12:30 PM, Tal Nisan wrote: > As noted yesterday a stable branch for oVirt Engine 4.0 was created. > From that mo

[ovirt-devel] [ATTN] oVirt Engine 4.0 stable branch was created

2016-05-25 Thread Tal Nisan
As noted yesterday a stable branch for oVirt Engine 4.0 was created. >From that moment on, every patch that has to be included in 4.0 will have to be backported to that stable branch. Note that as in all stable branches, a Bug-Url is mandatory and patches without a bug <=4.0 will not be merged. As

Re: [ovirt-devel] FD leak while initializing vdsm

2016-05-25 Thread Martin Sivak
> but it should > not try to implement __del__ - we had lot of trouble with such code in vdsm. Del is perfectly fine if done properly. Python objects should really clean after themselves. It is common to abstract the user from the low level networking code. For example all the SocketServer or xmlr

Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine

2016-05-25 Thread Martin Sivak
Hi, I do not remember exacly, but you might check the source code of hosted engine's VdsmBackend where we do that too. https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-ha.git;a=blob;f=ovirt_hosted_engine_ha/lib/storage_backends.py;h=f2fbdc43d0e4afd7539a3a1de75de0cb07bdca9d;hb=a012f184584af20

Re: [ovirt-devel] Gluster verbs are not working in latest VDSM build

2016-05-25 Thread Ramesh Nachimuthu
- Original Message - > From: "Piotr Kliczewski" > To: "Ramesh Nachimuthu" > Cc: "devel" , "Dan Kenigsberg" , "Yaniv > Bronheim" > Sent: Wednesday, May 25, 2016 2:23:46 PM > Subject: Re: Gluster verbs are not working in latest VDSM build > > On Wed, May 25, 2016 at 10:47 AM, Ramesh

Re: [ovirt-devel] Gluster verbs are not working in latest VDSM build

2016-05-25 Thread Piotr Kliczewski
On Wed, May 25, 2016 at 10:47 AM, Ramesh Nachimuthu wrote: > > > > > - Original Message - > > From: "Piotr Kliczewski" > > To: "Ramesh Nachimuthu" > > Cc: "devel" , "Dan Kenigsberg" , > "Yaniv Bronheim" > > Sent: Wednesday, May 25, 2016 1:46:45 PM > > Subject: Re: Gluster verbs are not

Re: [ovirt-devel] Gluster verbs are not working in latest VDSM build

2016-05-25 Thread Ramesh Nachimuthu
- Original Message - > From: "Piotr Kliczewski" > To: "Ramesh Nachimuthu" > Cc: "devel" , "Dan Kenigsberg" , "Yaniv > Bronheim" > Sent: Wednesday, May 25, 2016 1:46:45 PM > Subject: Re: Gluster verbs are not working in latest VDSM build > > Ramesh, > > In Bridge.py we only load gl

Re: [ovirt-devel] Gluster verbs are not working in latest VDSM build

2016-05-25 Thread Piotr Kliczewski
Ramesh, In Bridge.py we only load gluster schema when: if _glusterEnabled: paths.append(vdsmapi.find_schema('vdsm-api-gluster')) which is determine by: try: import gluster.apiwrapper as gapi import gluster.exception as ge _glusterEnabled = True except ImportError