Re: [ovirt-devel] Vdsm: extending maintainers team

[ybronhei]

On 08/04/2015 11:58 AM, Dan Kenigsberg wrote:

If you follow Vdsm development, you probably have noticed that we are
short of active maintainers.

Thankfully, we have have great developers that - in my opinion - can
fill that gap. I am impressed by the quality of their reviews, their
endurance, and most importantly - their ability to unbreak whatever
code they approve.

I'd like to nominate
- Nir Soffer - for storage
- Francesco Romani - for virt
- Piotr Kliczewski - for infra

For the mean while, I would like to keep my own single point of merger
(unless I'm away, of course).

Active and former maintainers: please approve


+1

well deserved.


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel




--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] Issue with vdsm on EL6 nodes

[ybronhei]

On 04/12/2015 12:17 PM, ybronhei wrote:

On 04/07/2015 04:45 PM, Alon Bar-Lev wrote:



- Original Message -

From: "knarra" 
To: "Alon Bar-Lev" 
Cc: us...@ovirt.org
Sent: Tuesday, April 7, 2015 3:39:58 PM
Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes

On 04/07/2015 05:58 PM, Alon Bar-Lev wrote:


- Original Message -

From: "knarra" 
To: "Alon Bar-Lev" 
Cc: us...@ovirt.org
Sent: Tuesday, April 7, 2015 3:25:07 PM
Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes

On 04/07/2015 05:50 PM, Alon Bar-Lev wrote:

- Original Message -

From: "knarra" 
To: us...@ovirt.org
Sent: Tuesday, April 7, 2015 3:15:12 PM
Subject: [ovirt-users] Issue with vdsm on EL6 nodes





SSLError: [Errno 1] _ssl.c:1390: error:1409442E:SSL
routines:SSL3_READ_BYTES:tlsv1 alert protocol version

Can some one help me to resolve this issue.

your openssl is patched to disable ssv3, and engine is trying to
communicate using sslv3.

please upgrade engine to latest z-stream, it should be resolved.

Hi Alon,

   I checked the following value in my database and my engine
is using
TLSv1 and not sslv3 to comminucate. I am on 3.6 master branch.

engine=# select option_name,option_value from vdc_options where
option_name = 'VdsmSSLProtocol';
  option_name   | option_value
-+--
VdsmSSLProtocol | TLSv1
(1 row)

hmmm and you say you get this when you use vdsClient, so maybe
it tries
to connect using sslv3.

is engine working proberly?

yes, engine works fine, i have few other nodes where i have the same
vdsm version added to same engine and i do not hit this issue there. I
am just wondering how is this happening.



compare openssl version.

yaniv, please fix the vdsClient to use TLSv1


should it use v1 always (forcefully)? we can do that, but currently it
chooses the highest version both parties are able to use


Vdsm uses ssl.PROTOCOL_SSLv23 which chooses the right tls version in 
python 2.7. In el6 we have python 2.6 which picks sslv2 or sslv3 when 
using ssl.PROTOCOL_SSLv23 (the highest version both sides support) -


ovirt 3.6 (vdsm 4.17 and above) doesn't support el6 anymore therefore 
current 3.6 code works as expected in el7\fedora>20.


If we want to fix vdsm 4.16.x (ovirt 3.5 package) to use explicitly 
ssl.PROTOCOL_TLSv1 we can do so - but it will be ovirt-3.5 branch only


do we want that? if so we need bug for 3.5

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Broken dependency for VDSM

[ybronhei]

On 03/19/2015 02:17 PM, Timothy Asir Jeyasingh wrote:

Blivet returns the unit size as an object (blivet.size) in blivet version  >= 
0.61.14 which is available in F21. We thought that using size object will be more 
clearer; because it provides unit type and some more functionality to change from 
one unit to another easily. But unfortunately the lower version in F20 just return 
the size in MiB (not an object).

I will fix this issue by sending a patch to vdsm to check the unit type of the 
device and fetch the value accordingly and remove any buildRequire version for 
the python-blivet package in the spec file. So that it can be build and work in 
F20

please do that asap or accept the revert and push it back after you have 
this fix.. we can't keep it that way

Regards,
Tim

- Original Message -

From: "Sandro Bonazzola" 
To: "Francesco Romani" , "Dan Kenigsberg" 

Cc: "Timothy Asir" , "Bala.FA" , 
devel@ovirt.org
Sent: Thursday, March 19, 2015 5:17:15 PM
Subject: Re: [ovirt-devel] Broken dependency for VDSM

Il 19/03/2015 12:08, Francesco Romani ha scritto:

- Original Message -

From: "Dan Kenigsberg" 
To: "Sandro Bonazzola" , "Timothy Asir"
, "Bala.FA" 
Cc: devel@ovirt.org
Sent: Thursday, March 19, 2015 12:06:22 PM
Subject: Re: [ovirt-devel] Broken dependency for VDSM

On Thu, Mar 19, 2015 at 09:00:27AM +0100, Sandro Bonazzola wrote:

Hi,
a recent change introduced a dependency on python-blivet >= 0.61.14 which
is not available at least on Fedora 20

Please provide the required package or ask fedora maintainer to backport
to
Fedora 20.
http://koji.fedoraproject.org/koji/packageinfo?packageID=15389


The faulty patch is

 gluster: add createBrick verb
 https://gerrit.ovirt.org/35498

Timothy, please make sure that Vdsm builds again on f20. The bare
minimum is

-%if 0%{?rhel} > 6 || 0%{?fedora}
+%if 0%{?rhelf 0%{?rhel} > 6 || 0%{?fedora}
+%if 0%{?rhel} > 6 || 0%{?fedora} > 20
  BuildRequires: python-blivet >= 0.61.14


Please also note that centos 7 ships

python-blivet-0.18.34-1.el7.noarch


CentOS 7.1 deliver 0.61.0.26 so it's not satisfied in CentOS 7.1 as well.
http://mirror.centos.org/centos/7/cr/x86_64/Packages/python-blivet-0.61.0.26-1.el7.noarch.rpm




Bests,




--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel




--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] python-cpopen

[ybronhei]

On 02/16/2015 04:27 PM, Sandro Bonazzola wrote:

Hi,
I'm looking at python-cpopen package as missing dependency for building VDSM 
within CentOS Virt SIG.
I see that Fedora and EPEL have version 1.3 but I see that our git repository 
has the following tags:

$ git remote -v
origin  git://gerrit.ovirt.org/cpopen (fetch)
origin  git://gerrit.ovirt.org/cpopen (push)

$ git tag --list
1.3.0
1.3.1
v1.4

We don't have jenkins build for cpopen, we rely on Fedora and EPEL releases.
I see also that the tar.gz used for building the Fedora RPM is not matching any 
of the above tags:
http://bronhaim.fedorapeople.org/cpopen-1.3.tar.gz
and it doesn't exist anymore.

I suggest to build cpopen-1.4 from v1.4 tag and publish the .tar.gz on oVirt 
site.
Then bump version on Fedora and EPEL to 1.4 accordingly.

Please keep aligned tags and tarball versions or it will become a nightmare to 
track issues between them.

That said, is v1.4 to be considered as formally released? Should I build from 
that tag for CentOS Virt SIG?


Hey,

I published 1.3-5 
https://brewweb.devel.redhat.com/buildinfo?buildID=420253 for el7 to 
have ppc build for cpopen


It is testing release from my point of view. 1.3-4 still the official 
and available for all dists (in koji and brew)


1.4 is current master and we haven't got there yet to publish 1.4 package.

I didn't upload updated tarball to the fedorapeople account so the link 
in the spec will direct you to older version [1] - which I'll fix


the build that should be used in addition to ovirt repo for vdsm is 
1.3-4 and it's available
we can make a job for those sub packages as well (cpopen, ioprocess, 
pthreading ..), should be quite easy and we already have infra for that


[1] http://bronhaim.fedorapeople.org/cpopen-1.3.tar.gz

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) to Cluster 3.6

[ybronhei]

On 02/10/2015 05:39 PM, Michael Burman wrote:

Hello Yaniv and all!

So i did this:
I tried to install clean rhel7.1 host with the right libvirt 
version(libvirt-1.2.8-16.el7.x86_64,vdsm-4.17.0-394.gitb237397.el7.x86_64) and 
failed to join this host under 3.6 cluster.
Host red-vds2.qa.lab.tlv.redhat.com is compatible with versions 
(3.0,3.1,3.2,3.3,3.4,3.5) and cannot join Cluster mb3.6 which is set to version 
3.6.
After failing i checked the /usr/share/vdsm/dsaversion.py and saw that:
version_info = {
 'version_name': version_name,
 'software_version': software_version,
 'software_revision': software_revision,
 'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5'],
 'supportedProtocols': ['2.2', '2.3'],
 'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5'],

So i added the 3.6 for cluster levels and engine support lines, restarted vdsm 
and finally managed to join my rhel7.1 host to 3.6 Cluster.

All of this means that rhel7.1 hosts with vdsm 4.17.0 and libvirt version 
-libvirt-1.2.8-16.el7.x86_64 are still not supported by default for 3.6 
clusters and dsaversion.py file must be edited manually in order to join to 
cluster 3.6.
I guess this must be changed.
of course it doesn't.. we still didn't merge 
http://gerrit.ovirt.org/#/c/37384/ . but with libvirt >1.2.3 you are 
able to hack dsaversion to report also 3.6 and use it.
we still struggling to define the approach to go with 
http://gerrit.ovirt.org/#/c/37598/
one of those patches need to get in to allow adding any host to 3.6 
cluster without additional hack


Best regards,
Michael B


- Original Message -
From: "Michael Burman" 
To: "ybronhei" 
Cc: devel@ovirt.org, in...@ovirt.org
Sent: Monday, February 9, 2015 10:50:28 AM
Subject: Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64)
to Cluster 3.6

Thank you all!

Ok, so how can i get this right libvirt version for rhel7? not7.1 and without 
any dependencies issues??
I want to join rhel7 host, with the right libvirt version to 3.6 cluster..is it 
possible?

Michael B


- Original Message -
From: "ybronhei" 
To: "Oved Ourfali" , "Sandro Bonazzola" , "Dan 
Kenigsberg" 
Cc: in...@ovirt.org, devel@ovirt.org, "Michael Burman" 
Sent: Monday, February 9, 2015 10:03:56 AM
Subject: Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) to 
Cluster 3.6

On 02/09/2015 08:35 AM, Oved Ourfali wrote:


On Feb 9, 2015 9:31 AM, Sandro Bonazzola  wrote:


Il 08/02/2015 16:15, Michael Burman ha scritto:

Hi everyone!

Is any one knows when it will be possible to join vdsm-4.17.0 to 3.6 Cluster??
I know that the libvirt version is not supported, but isn't should be? even if 
it's rhel7..?

I changed the /usr/share/vdsm/dsaversion.py file to:
'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'],
   'supportedProtocols': ['2.2', '2.3'],
   'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'],

But caps.py is still:
if not hasattr(libvirt, 'VIR_MIGRATE_AUTO_CONVERGE'):
   return _dropVersion('3.6',
   'VIR_MIGRATE_AUTO_CONVERGE not found in libvirt,'
   ' support for clusterLevel >= 3.6 is disabled.'
   ' For Fedora 20 users, please consider upgrading'
   ' libvirt from the virt-preview repository')

   if not hasattr(libvirt, 'VIR_MIGRATE_COMPRESSED'):
   return _dropVersion('3.6',
   'VIR_MIGRATE_COMPRESSED not found in libvirt,'
   ' support for clusterLevel >= 3.6 is disabled.'
   ' For Fedora 20 users, please consider upgrading'
   ' libvirt from the virt-preview repository')

libvirt is still disabled for 3.6 clusters...


I already tried to rebuild from fedora(with Sandro appreciated help), but had a 
lot of issues dependencies.

I'm running on-
ovirt-engine-3.6.0-0.0.master.20150206122208.gitd429375.el6.noarch
vdsm-4.17.0-390.gita3163f3.el7.x86_64
libvirt-1.1.1-29.el7_0.7.x86_64

I would like to know if and when it will be possible to join rhel7 
host(vdsm-4.17.0) to Cluster 3.6?


Moving to devel list, not really an infra issue.



Yaniv, you had a patch for that, but it was abandoned. Why?

Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) to Cluster 3.6

[ybronhei]

On 02/09/2015 08:35 AM, Oved Ourfali wrote:


On Feb 9, 2015 9:31 AM, Sandro Bonazzola  wrote:


Il 08/02/2015 16:15, Michael Burman ha scritto:

Hi everyone!

Is any one knows when it will be possible to join vdsm-4.17.0 to 3.6 Cluster??
I know that the libvirt version is not supported, but isn't should be? even if 
it's rhel7..?

I changed the /usr/share/vdsm/dsaversion.py file to:
'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'],
  'supportedProtocols': ['2.2', '2.3'],
  'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'],

But caps.py is still:
if not hasattr(libvirt, 'VIR_MIGRATE_AUTO_CONVERGE'):
  return _dropVersion('3.6',
  'VIR_MIGRATE_AUTO_CONVERGE not found in libvirt,'
  ' support for clusterLevel >= 3.6 is disabled.'
  ' For Fedora 20 users, please consider upgrading'
  ' libvirt from the virt-preview repository')

  if not hasattr(libvirt, 'VIR_MIGRATE_COMPRESSED'):
  return _dropVersion('3.6',
  'VIR_MIGRATE_COMPRESSED not found in libvirt,'
  ' support for clusterLevel >= 3.6 is disabled.'
  ' For Fedora 20 users, please consider upgrading'
  ' libvirt from the virt-preview repository')

libvirt is still disabled for 3.6 clusters...


I already tried to rebuild from fedora(with Sandro appreciated help), but had a 
lot of issues dependencies.

I'm running on-
ovirt-engine-3.6.0-0.0.master.20150206122208.gitd429375.el6.noarch
vdsm-4.17.0-390.gita3163f3.el7.x86_64
libvirt-1.1.1-29.el7_0.7.x86_64

I would like to know if and when it will be possible to join rhel7 
host(vdsm-4.17.0) to Cluster 3.6?


Moving to devel list, not really an infra issue.



Yaniv, you had a patch for that, but it was abandoned. Why?

because we don't need it- i explained there
the cluster check is only after the supportedVDSMVersion does not catch. 
we failed to add the host to the cluster because the libvirt version . 
as it is now, with the right versions, you should be able to add vdsm 
4.17 to lastest engine regardless the cluster level




Best regards,

Michael B






--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] python-blivet requirement not available on el6

[ybronhei]

On 01/19/2015 12:55 PM, Sandro Bonazzola wrote:

Hi, looks like vdsm added a dependency not available on EPEL 6.

http://jenkins.ovirt.org/job/repos_master_check-closure_merged/DISTRIBUTION=centos6/388/console


package: vdsm-4.17.0-283.gite127687.el6.x86_64 from check-custom-el6
   unresolved deps:
  python-blivet
package: vdsm-4.17.0-292.git0b55852.el6.x86_64 from check-custom-el6
   unresolved deps:
  python-blivet

Can you share some details about this requirement?
Is anybody working with epel maintainer to get this in el6?

http://gerrit.ovirt.org/#/c/37010/2/vdsm.spec.in,cm limits it. we need 
it only over rhel>=7 or fedora


--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] fyi ovirt-engine\api fails over f19

[ybronhei]

Hey guys,

I faced a problem with javax/activation/api which is missing in f19.
Therefore /api threw exception and I couldn't have any restapi reply 
from engine.
To workaround with that instead upgrading I removed the dependency from 
share/ovirt-engine/modules/org/codehaus/jackson/jackson-xc/main/module.xml 
and it works. till now i haven't noticed anything strange without it..


Regards,

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Vdsm 4.16.10 build - oVirt-3.5

[ybronhei]

Hey,
Enjoy the new updates of vdsm 4.16.10.

epel7 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8479594
f20 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8495492
f21 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8494079
f22 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8494059

for el6 I still have few problems to set it up
(https://kojipkgs.fedoraproject.org//work/tasks/5530/8495530/mock_output.log), 
I'll update about it


Please give karama if works properly
Regards,

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt on el6 and novcn rpm from epel

[ybronhei]

On 12/22/2014 07:29 PM, Simone Tiraboschi wrote:

Hi All,
two days ago novnc rpm has been retired from EPEL-6 [1]. We have a dependencies 
from it and some user is already complaining he cannot install oVirt 3.5.0 on 
Centos 6.6.

The reason seams a broken deps on openstack-nova-novncproxy-0.4-2.el6.noarch [2]

[1] - https://admin.fedoraproject.org/pkgdb/package/novnc/
[2] - http://pkgs.fedoraproject.org/cgit/novnc.git/commit/?h=el6

What should we do?
a. include and maintain it on our repo
b. find somebody else to maintain on EPEL-6
c. release the dependencies if not really needed

ciao,
Simone
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



any workaround with that?

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Fwd: Got an error after buuilding VDSM on latest upstream commit

[ybronhei]

forwarding to devels

anyone familiar with the issue already ? any ready patch?


 Forwarded Message 
Subject: Got an error after buuilding VDSM on latest upstream commit
Date: Sun, 30 Nov 2014 05:54:45 -0500 (EST)
From: Eli Mesika 
To: Dan Kenigsberg , Saggi Mizrahi 
, ybronhei , Dima Kuznetsov 


CC: Oved Ourfali , Barak Azulay 

vdsm: Running restore_nets
libvirt: Network Driver error : Network not found: no network with 
matching name 'vdsm-ovirtmgmt'

^X^CTraceback (most recent call last):
  File "/usr/share/vdsm/vdsm-restore-net-config", line 139, in 
restore()
  File "/usr/share/vdsm/vdsm-restore-net-config", line 125, in restore
unified_restoration()
  File "/usr/share/vdsm/vdsm-restore-net-config", line 70, in 
unified_restoration

setupNetworks(nets, bonds, connectivityCheck=False, _inRollback=True)
  File "/usr/share/vdsm/network/api.py", line 715, in setupNetworks
implicitBonding=True, _netinfo=_netinfo, **d)
  File "/usr/share/vdsm/network/api.py", line 221, in wrapped
ret = func(**attrs)
  File "/usr/share/vdsm/network/api.py", line 310, in addNetwork
netEnt.configure(**options)
  File "/usr/share/vdsm/network/models.py", line 196, in configure
self.configurator.configureBridge(self, **opts)
  File "/usr/share/vdsm/network/configurators/ifcfg.py", line 92, in 
configureBridge

ifup(bridge.name, bridge.ipConfig.async)
  File "/usr/share/vdsm/network/configurators/ifcfg.py", line 820, in ifup
rc, out, err = _ifup(iface)
  File "/usr/share/vdsm/network/configurators/ifcfg.py", line 804, in _ifup
rc, out, err = utils.execCmd([constants.EXT_IFUP, netIf], raw=False)
  File "/usr/lib/python2.6/site-packages/vdsm/utils.py", line 622, in 
execCmd

(out, err) = p.communicate(data)
  File "/usr/lib64/python2.6/subprocess.py", line 732, in communicate
stdout, stderr = self._communicate(input, endtime)
  File "/usr/lib64/python2.6/subprocess.py", line 1316, in _communicate
stdout, stderr = self._communicate_with_poll(input, endtime)
  File "/usr/lib64/python2.6/subprocess.py", line 1388, in 
_communicate_with_poll

ready = poller.poll(self._remaining_time(endtime))



Any ideas ???

Thanks
Eli Mesika


--
Yaniv Bronhaim.


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] What does your oVirt development environment look like?

[ybronhei]

On 08/15/2014 09:32 AM, Adam Litke wrote:

Ever since starting to work on oVirt around 3 years ago I've been
striving for the perfect development and test environment.  I was
inspired by Yaniv's recent deep dive on Foreman integration and
thought I'd ask people to share their setups and any tips and tricks
so we can all become better, more efficient developers.

My setup consists of my main work laptop and two mini-Dell servers.  I
run the engine on my laptop and I serve NFS and iSCSI (using
targetcli) from this system as well.  I use the ethernet port on the
laptop to connect it to a subnet with the two Dell systems.

Some goals for my setup are:
- Easy provisioning of the virt-hosts so I can quickly test on Fedora
   and CentOS without spending lots of time reinstalling
- Ability to test block and nfs storage
- Automation of test scenarios involving engine and hosts

To help me reach these goals I've deployed cobbler on my laptop and it
does a pretty good job at managing PXE boot configurations for my
hosts (and VMs) so they can be automatically intalled as needed.
After viewing Yaniv's presentation, it seems that Forman/Puppet are
the way of the future but it does seem a bit more involved to set up.
I am definitely curious if others are using Foreman in their personal
dev/test environment and can offer some insight on how that is working
out.

Thanks, and I look forward to reading about more of your setups!  If
we get enough of these, maybe this could make a good section of the
wiki.

Heppy to hear :) for those who missed - 
https://www.youtube.com/watch?v=gozX891kYAY


each one has its own needs and goals I guess, but if you say it might 
help, I'll never say no for sharing :P
I have 3 dells under my desk, I compile the engine a lot and its heavy 
for my laptop. So I clone my local working directory and build it on the 
strongest mini-dell using local jenkins server 
(http://www.ovirt.org/Local_Jenkins_For_The_People). The other 2 I use 
as hypervisor when needed. provision them is done by me manually :/.. 
cobbler pxe boot could help with already defined image..  Other then 
that, I have nfs mount for storage and few vms for compilation and small 
tests


sorry I can't help with your curiosity .. my env quite simple

Regards,
Yaniv Bronhaim.

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Test-Day 3.5-2 -> Import Storage Domain

[ybronhei]

Hey all,

following the updated wikis - 
http://www.ovirt.org/Features/ImportUnregisteredEntities and 
http://www.ovirt.org/Features/ImportStorageDomain which describe in 
details the steps for import storage domain I successfully created a 
cluster with 1 hosts and 3 vms.

(host and engine run with rhel6.5)

Changed some of the details for the vms (ha, system infos, mem, cpus and 
more), then cleaned up the engine (ran engine-cleanup and rerun 
engine-setup). On clean environment I created new cluster with new 
storage domain (its a must currently to create new storage domain before 
the import - stated in the [1]). After that I imported the original sd 
that I used, went to import Virtual machines tab and imported all 
entities I had.


All of the vms' details were imported successfully with the same info 
that I configured before the cleanup.


Tried again also with templates and snapshots recovery, also worked as 
expected


seems green to me.

anything else you would like me to check in this area?

[1] http://www.ovirt.org/Features/ImportStorageDomain#Implementation_gaps

Thanks,
--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] vdsm 4.16.1 - ovirt 3.5 beta2

[ybronhei]

For your use

f20 http://koji.fedoraproject.org/koji/taskinfo?taskID=7198657
f19 http://koji.fedoraproject.org/koji/taskinfo?taskID=7198683
el6 http://koji.fedoraproject.org/koji/taskinfo?taskID=7198697
el7 http://koji.fedoraproject.org/koji/taskinfo?taskID=7198799

Thanks,
--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] noarch vdsm.rpm

[ybronhei]

On 07/24/2014 03:42 PM, Dan Kenigsberg wrote:

On Thu, Jul 24, 2014 at 07:37:45AM -0400, Martin Sivak wrote:

I am pretty sure you have to tell rpm that it is supposed to be noarch package:

BuildArch: noarch

I do not see that anywhere in that patch.


Thanks, it did the trick.

Now the only problem is the x86_64-only dmidecode requirement.
Yaniv, can it be changed to a soft requirement?
s
yes, this is actually not needed as build requirement , if that's what 
you mean


http://gerrit.ovirt.org/30682

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm-4.14.11-2 New build for ovirt-3.4

[ybronhei]

On 07/23/2014 06:21 PM, Douglas Schilling Landgraf wrote:

On 07/23/2014 05:25 AM, ybronhei wrote:

On 07/23/2014 12:21 PM, Dan Kenigsberg wrote:

On Wed, Jul 23, 2014 at 12:50:07AM +0300, ybronhei wrote:

Hey all,

New build of vdsm for ovirt-3.4 is available:

f20 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7178863
f19 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182758
el6 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182831
el7 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182808


Thank, Yaniv. Do you have any idea why only the f20 build shows up on
https://admin.fedoraproject.org/updates/search/vdsm ? I wanted to give
karma to the el6 build. (I bet that others wants to see it out asap)


yes, now f19 also should be there

and for el6 , we don't have such branch in the fedpkg repo, I only made
a scratch-build
Douglas - is there a way to publish also el6 and epel7 update when we do
only scrach-build?


No, if you want a fedora 'build/update' you must have the branch.
To request new branches for VDSM, please go to:
https://bugzilla.redhat.com/show_bug.cgi?id=745510

Example:
https://bugzilla.redhat.com/show_bug.cgi?id=745510#c23 raising the flag
fedora-cvs.

More info: http://fedoraproject.org/wiki/Package_SCM_admin_requests

can you take care of that? looks like you need to be fedora packager for 
that, i can't set the fedora-cvs flag


only need to post:

Package Change Request
==
Package Name: vdsm
New Branches: el6 epel7
Owners: fsimonce danken smizrahi

as far as i understand the process, and reopen the bug

Thanks,
--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm-4.14.11-2 New build for ovirt-3.4

[ybronhei]

On 07/23/2014 12:21 PM, Dan Kenigsberg wrote:

On Wed, Jul 23, 2014 at 12:50:07AM +0300, ybronhei wrote:

Hey all,

New build of vdsm for ovirt-3.4 is available:

f20 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7178863
f19 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182758
el6 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182831
el7 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182808


Thank, Yaniv. Do you have any idea why only the f20 build shows up on
https://admin.fedoraproject.org/updates/search/vdsm ? I wanted to give
karma to the el6 build. (I bet that others wants to see it out asap)


yes, now f19 also should be there

and for el6 , we don't have such branch in the fedpkg repo, I only made 
a scratch-build
Douglas - is there a way to publish also el6 and epel7 update when we do 
only scrach-build?


--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] vdsm-4.14.11-2 New build for ovirt-3.4

[ybronhei]

Hey all,

New build of vdsm for ovirt-3.4 is available:

f20 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7178863
f19 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182758
el6 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182831
el7 - http://koji.fedoraproject.org/koji/taskinfo?taskID=7182808

Thanks,
--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] python-pthreading 0.1.3-3

[ybronhei]

Hello everybody,

Few days ago we published python-pthreading 0.1.3-2 which included a 
patch ([1]) that fixes urgent bug in ovirt ([2])


Today we found out that this build also includes a patch (called 
monkey_patch: Fail if it is too late to monkey-patch) that introduces 
regression with older versions of ovirt. Therefore we publish new build 
(0.1.3-3) that includes only the required fix. Please test and give it a 
karma for your environment, if you can [3] [4] [5] [6] [7]


Thanks,

[1] Add the missing locked() interface
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1117795
[3] http://koji.fedoraproject.org/koji/buildinfo?buildID=543650 (el6)
[4] http://koji.fedoraproject.org/koji/buildinfo?buildID=543651 (f19)
[5] http://koji.fedoraproject.org/koji/buildinfo?buildID=543653 (f20)
[6] http://koji.fedoraproject.org/koji/buildinfo?buildID=543649 (f21)
[7] http://koji.fedoraproject.org/koji/buildinfo?buildID=543655 (el7)

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] compile vdsm and attach it to a engine.

[ybronhei]

On 07/03/2014 05:11 AM, aaron Beein wrote:

Hi,

Thank you for your great job on ovirt and vdsm. Now I devote myself to
compile vdsm on centos 6.3 host and attach it to a ovirt engine. But when I
attach the host which contains a compiled vdsm to a ovirt engine , the
status of the host is always ‘Non Responsive’(step 11 below). I reference
the links below:

http://www.ovirt.org/Vdsm_Developers

http://www.ovirt.org/Installing_VDSM_from_rpm



The steps( 1-9 ) are executed on centos6.3 host, and the steps(10--11) are
executed on ovirt engine. So I would be very grateful if you can give me
some clues that if I've missed anything or I done something wrong.

The attachment is the same as the bellow which makes it easier for you to
read.
1 Deployment platform

  Centos6.3

  Linux bogon 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux

  Ip ： 10.1.8.252

CPU supports hardware virtualization extensions:

# cat /proc/cpuinfo | egrep 'svm|vmx'| grep nx

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc
aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr
pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm arat epb
xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc
aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr
pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm arat epb
xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
  2 Apply all updates # yum  -y update  3 Installing required packages

RHEL 6 users must add EPEL yum repository for installing python-ordereddict
and pyton-pthreading. The rpm bellow will install the epel yum repo and
required gpg keys.

# yum install 
http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

RHEL 6 users must install a newer pep8 version than the one shipped in
EPEL6. Older pep8 versions have a bug that's tickled by vdsm. You can use
`pip`, or

yum install http://danken.fedorapeople.org/python-pep8-1.4.5-2.el6.noarch.rpm

oVirt repo:

yum install http://resources.ovirt.org/releases/ovirt-release.noarch.rpm

RHEL 6 users must add the glusterfs repository, providing newer glusterfs
not available on RHEL 6. Optionally install 'wget' if not present

rpm -q wget 2> /dev/null || yum install wget

wget -O /etc/yum.repos.d/glusterfs-epel.repo
*http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/glusterfs-epel.repo*


Fedora and RHEL 6 users must verify the following packages are installed
before attempting to build:

  yum install make autoconf automake pyflakes logrotate gcc python-pep8
libvirt-python python-devel \

  python-nose rpm-build sanlock-python genisoimage python-ordereddict
python-pthreading libselinux-python\

  python-ethtool m2crypto python-dmidecode python-netaddr
python-inotify python-argparse git \

python-cpopen bridge-utils libguestfs-tools-c pyparted openssl libnl
libtool gettext-devel python-ioprocess  libvirt libvirt-client
libvirt-lock-sanlock

4 Getting the source

cd /root

git clone *http://gerrit.ovirt.org/p/vdsm.git*


cd vdsm

   5 Building a Vdsm RPM

./autogen.sh –system



./configure --prefix=/usr --sysconfdir=/etc--localstatedir=/var
--libdir=/usr/lib   --enable-hooks

make rpm NOSE_EXCLUDE=.*
6 Basic installation and start

When building from source, you should enable the ovirt-beta repository, to
satisfy dependencies that are not available yet in the release repository.

# cd ~/rpmbuild/RPMS

# yum install  --skip-broken
--enablerepo=ovirt-master-snapshot-static x86_64/* noarch/vdsm-xml*
noarch/vdsm-cli* noarch/vdsm-python-zombiereaper*
noarch/vdsm-*jsonrpc*



Before starting vdsmd service for the first time vdsm requires some
configuration procedures for external services that being used by vdsmd. To
ease this process vdsm provides a utility (vdsm-tool). To perform full
reconfiguration of external services perform:

# vdsm-tool configure --force

(for more information read "vdsm-tool --help")




7 Finally start the vdsmd service

# service vdsmd start


8  Yum install -y bridge-utils

Configuring the bridge Interface as below

Disable the network manager service by executing as root:

systemctl stop NetworkManager.service

systemctl disable NetworkManager.service



service network start

chkconfig network on

Add the following content into a new file named:
*/etc/sysconfig/network-scripts/ifcfg-ovirtmgmt*:

DEVICE=ovirtmgmt

TYPE=Bridge

ONBOOT=yes

DELAY=0

Re: [ovirt-devel] ovirt 3.5 Test day 1 - vdsm-tool configure libvirt with python code

[ybronhei]

On 07/03/2014 06:11 PM, Yedidyah Bar David wrote:

- Original Message -

From: "ybronhei" 
To: "Yedidyah Bar David" , devel@ovirt.org
Sent: Thursday, July 3, 2014 6:05:52 PM
Subject: Re: [ovirt-devel] ovirt 3.5 Test day 1 - vdsm-tool configure libvirt 
with python code

On 07/01/2014 05:13 PM, Yedidyah Bar David wrote:

Hi all,

I was assigned to test [1], which was fixed by [2], which pointed
at [3].

Most things worked as expected.

Issues I noticed:

* the table says that vdsClient with or without '-s' should work against
vdsm with ssl=true or ssl=false. In my tests '-s' worked with true, without
'-s' worked with false, but the other options didn't work.


"vdsClient -s" means to use secure communication, which will work
properly if "ssl=true" is configured in vdsm.conf (btw, if ssl not
specified there true is the default).

bare in mind, that after changing the conf file you need to restart
vdsmd service.

when you change vdsm.conf like "ssl=true" to "ssl=false", before running
vdsmd again, you need to perform "vdsm-tool configure" to configure all
related service to work properly with the new vdsm configuration (in
that case, not secured which require libvirtd.conf and qemu.conf update)

after vdsm-tool configures libvirtd.conf and qemu.conf accordingly , you
can start vdsmd and see that "vdsClient" (without -s) works properly.

this works as far as I checked in vdsm 3.5


Not sure I got you right - with the above (edit/configure/restart), is it
intended that '-s' will work with 'ssl=false'? Because iirc it didn't.
-s means secured, and you set ssl=false. so no, when you set ssl to 
false, vdsClient with -s should not work.


I do not think it's important that it works - if a user wants ssl they should
obviously do 'ssl=true' and '-s', and if not, 'ssl=false' and no '-s'. The
only reason I tested this and point out above is that it is mentioned in the
wiki table that it's supposed to work and it didn't for me (again, if I
understood everything correctly).


mooli, maybe the wiki misleading in that area. consider to update it





--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] ovirt 3.5 Test day 1 - Import Storage Domain

[ybronhei]

Hey,
I assigned myself to the Import Storage Domain feature [1] in the first
ovirt 3.5 test day

Currently I checked that when setting OvfUpdateIntervalInMinutes (on 
vdc_options) to 2 minutes, it saves the ovf files as expected. After 
setting up new environment and importing the same nfs path that I used 
as storage domain, ovirt recovered my setup properly


I'll play with it more on second test day.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1083307

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt 3.5 Test day 1 - vdsm-tool configure libvirt with python code

[ybronhei]

On 07/01/2014 05:13 PM, Yedidyah Bar David wrote:

Hi all,

I was assigned to test [1], which was fixed by [2], which pointed
at [3].

Most things worked as expected.

Issues I noticed:

* the table says that vdsClient with or without '-s' should work against
vdsm with ssl=true or ssl=false. In my tests '-s' worked with true, without
'-s' worked with false, but the other options didn't work.

"vdsClient -s" means to use secure communication, which will work 
properly if "ssl=true" is configured in vdsm.conf (btw, if ssl not 
specified there true is the default).


bare in mind, that after changing the conf file you need to restart 
vdsmd service.


when you change vdsm.conf like "ssl=true" to "ssl=false", before running 
vdsmd again, you need to perform "vdsm-tool configure" to configure all 
related service to work properly with the new vdsm configuration (in 
that case, not secured which require libvirtd.conf and qemu.conf update)


after vdsm-tool configures libvirtd.conf and qemu.conf accordingly , you 
can start vdsmd and see that "vdsClient" (without -s) works properly.


this works as far as I checked in vdsm 3.5


* the vdsm-tool package does not depend on vdsm, but
'vdsm-tool configure --force' fails without it.

I didn't open bugs on them because they seem insignificant.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1069636
[2] http://gerrit.ovirt.org/27298
[3] http://www.ovirt.org/Configure_libvirt_testing_matrix




--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] supervdsm defunct bug?

[ybronhei]

On 06/18/2014 01:55 PM, Dan Kenigsberg wrote:

On Wed, Jun 18, 2014 at 09:20:06AM +, Sven Kieske wrote:



Am 18.06.2014 11:05, schrieb Dan Kenigsberg:


Does the suggested patch http://gerrit.ovirt.org/#/c/27627/ solves the
problem and does not introduce new ones? If so, please mark it as
verified.

It awaits verification and more reviews, while we are busy in
even-more-urgent 3.5 chores.

Regards,
Dan.



Thanks for pushing with me for the review in order to avoid log spam.
You do not happen to know anything about the other
bug(supervdsm defunct), though?


Oh sorry, this email thread is overloaded a bit. I'm adding Yaniv to the
nag list. I hope he or Dima can prepare a quick fix for the pid leak.

I don't understand how is http://gerrit.ovirt.org/#/c/27627 related to 
the defunct problem. Sven, do you have constant flow that produce those 
defunct process? it can help. if you do, please update [1] with your 
steps, and logs might help too if you don't have such known flow


[1] https://bugzilla.redhat.com/show_bug.cgi?id=841486

Thanks

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ioprocess] Karma please

[ybronhei]

On 05/05/2014 11:35 AM, Saggi Mizrahi wrote:

I'd appreciate some karma.

https://admin.fedoraproject.org/updates/ioprocess-0.3-1.fc20


Hey all,
new version arrived and tagged - ioprocess 0.4
can you please give it some karma [1]

Thanks!

[1] https://admin.fedoraproject.org/updates/ioprocess-0.4-2.fc20

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] [PATCH] Add the missing locked() interface

[ybronhei]

On 05/07/2014 07:48 PM, Nir Soffer wrote:


threading.Lock has a little known locked() method, documented in
https://docs.python.org/2.6/library/thread.html#thread.lock.locked

This method is not very useful, but since pthreading.Lock must be
drop-in replacment for threading.Lock, we must implement it.

This patch adds the missing method, implementing it in the same way
Python implemnts it.  Since RLock does not have this method, RLock does
not extend Lock now.

Signed-off-by: Nir Soffer 
---
  pthreading.py | 18 ++
  tests.py  |  7 +++
  2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/pthreading.py b/pthreading.py
index 2e9e2d6..f1ea056 100644
--- a/pthreading.py
+++ b/pthreading.py
@@ -51,9 +51,9 @@ import os
  import pthread


-class Lock(pthread.Mutex):
+class _Lock(pthread.Mutex):
  """
-Lock class mimics Python native threading.Lock() API on top of
+_Lock class mimics Python native threading.Lock() API on top of
  the POSIX thread mutex synchronization primitive.
  """
  def __enter__(self):
@@ -78,9 +78,19 @@ class Lock(pthread.Mutex):
  self.unlock()


-class RLock(Lock):
+class Lock(_Lock):
+def locked(self):
+# Yes, this is horrible hack, and the same one used by Python
+# threadmodule.c. But this is part of Python lock interface.
+if self.acquire(blocking=False):
+self.release()
+return False
+return True
+
+
+class RLock(_Lock):
  def __init__(self):
-pthread.Mutex.__init__(self, recursive=True)
+_Lock.__init__(self, recursive=True)


  class Condition(object):
diff --git a/tests.py b/tests.py
index d651288..f4c9746 100644
--- a/tests.py
+++ b/tests.py
@@ -60,6 +60,13 @@ class LockTests(TestCaseBase):
  self.assertTrue(lock.acquire())
  self.assertTrue(lock.acquire(False))

+def testLocked(self):
+lock = pthreading.Lock()
+self.assertFalse(lock.locked())
+with lock:
+self.assertTrue(lock.locked())
+self.assertFalse(lock.locked())
+

  class Flag(object):
  def __init__(self):


+1
thanks

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] short recap of last vdsm call (15.4.2014)

[ybronhei]

On 04/30/2014 04:22 PM, Dan Kenigsberg wrote:

On Tue, Apr 22, 2014 at 02:54:29PM +0300, ybronhei wrote:

hey,

somehow we missed the summary of this call, and few "big" issues
were raised there. so i would like to share it with all and hear
more comments

- task id in http header - allows engine to initiate calls with id
instead of following vdsm response - federico already started this
work, and this is mandatory for live merge feature afaiu.


Adam, Federico, may I revisit this question from another angle?

Why does Vdsm needs to know live-merge's task id?
As far as I understand, (vmid, disk id) are enough to identify a live
merge process.

If we do not have a task id, we do not need to worry on how to pass it,
and where to persist it.

engine must polls somehow the process (/task) status to know when to end 
the action (with success or fail) and release locks


--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] short recap of last vdsm call (15.4.2014)

[ybronhei]

hey,

somehow we missed the summary of this call, and few "big" issues were 
raised there. so i would like to share it with all and hear more comments


- task id in http header - allows engine to initiate calls with id 
instead of following vdsm response - federico already started this work, 
and this is mandatory for live merge feature afaiu.


- fromani: Suggested thread pool for libvirt-related operations. if this 
can be elaborated more, please do. i don't recall the details or other 
alternatives.


- danken: we should press on with the patches that keep VMs in Down 
state: removing them on vdsm restart keeps lvs in activated state which 
may spell trouble


- splitting vdsm infra\generic code to sub-vdsm-module instead of 
creating separate packages. This can be done by splitting the git 
repository to allow "easy" maintenance of the code (from infra 
prospective) which includes also C parts and generic tools that can be 
used in other projects as well.


if i missed anything, please add

thanks,

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] [VDSM] pthreaing patches for review

[ybronhei]

On 04/21/2014 12:43 AM, Nir Soffer wrote:

Hi all,

Please review these patches for the pthreading package:

import-check branch:

- monkey_patch: Fail if it is too late to monkey-patch
   
https://github.com/nirs/pthreading/commit/490e837e0afed37823803d9e180a5d3eb17cb82c

   Note: this patch is waiting for review since Mar 8 without any response on 
the list.

event branch:

- Fix return value of Condition.wait()
   
https://github.com/nirs/pthreading/commit/2efade6ae9e9ad836cb9aa46bd203a976bfc6147

- Fix handling of spurious wakeups during wait
   
https://github.com/nirs/pthreading/commit/54b62c44526b4b3caf0f188738a66de6b59fe34f

- Update README.md about reimplemented objects
   
https://github.com/nirs/pthreading/commit/254e4c4b36075814d39f5f93671554c3a3fadd48

- Improve README.md formatting
   
https://github.com/nirs/pthreading/commit/6befacf0cc24932c1750291d4a030e0dbb7f23e2

Thanks
Nir
___
vdsm-devel mailing list
vdsm-de...@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel



thanks nir
i'll check that asap this week.
if others can review it as well I'll appreciate it

--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [Devel] Vdsm functional tests

[ybronhei]

On 04/07/2014 01:42 AM, Dan Kenigsberg wrote:

On Sun, Apr 06, 2014 at 11:18:19AM +0300, ybronhei wrote:

On 04/03/2014 07:31 PM, Douglas Schilling Landgraf wrote:

On 04/03/2014 11:08 AM, Dan Kenigsberg wrote:

Functional tests are intended to verify that a running Vdsm instance
does what it should, when treated as a black box, over its public API.

They should be comprehensive and representative of a typical field usage
of Vdsm. It is a sin to break such a test - but we must be able to know
when such a sin is committed.

We currently have the following functional tests modules:

- sosPluginTests.py
   supervdsmFuncTests.py


Sure, count with me.


any news about it ? need my help around it?


Douglas still owes me a time estimate on when this be done.


supervdsmFuncTests.py doesn't really check much. we need to add much
more logic there if we actually want to test the communication
between vdsm and supervdsm (not sure if its really required.. its
like checking calls to libvirt or sanlock or testing api calls)


At the moment supervdsmFuncTests do test that supervdsm is reponsive and
that supervdsm.getProxy() works. It's not like testing libvirt api calls
since supervdsm is inside our tree. So it's like testing libvirt api
calls - within the libvirt project.

I would embrace more smarter logic into the test - but I'm not sure what
you have in mind.


don't have yet. will think about it with douglas
if you or anyone else had any thought of infra's functional test, please 
raise it up and we'll work on it


--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [Devel] Vdsm functional tests

[ybronhei]

On 04/03/2014 07:31 PM, Douglas Schilling Landgraf wrote:

On 04/03/2014 11:08 AM, Dan Kenigsberg wrote:

Functional tests are intended to verify that a running Vdsm instance
does what it should, when treated as a black box, over its public API.

They should be comprehensive and representative of a typical field usage
of Vdsm. It is a sin to break such a test - but we must be able to know
when such a sin is committed.

We currently have the following functional tests modules:

- sosPluginTests.py
   supervdsmFuncTests.py


Sure, count with me.


any news about it ? need my help around it?
supervdsmFuncTests.py doesn't really check much. we need to add much 
more logic there if we actually want to test the communication between 
vdsm and supervdsm (not sure if its really required.. its like checking 
calls to libvirt or sanlock or testing api calls)




- storageTests.py

- momTests.py
   virtTests.py

- networkTests.py

I'd like to have a designated developer per team (infra, storage, virt
and
network), responsible to having these tests ever-running.

When could we expect to have it running per commit on a Jenkins slaves?

Volunteers, please come forward.

Dan.







--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [Devel] [vdsm] vdsm sync meeting minutes April 1st, 2014

[ybronhei]

Hey all,
back from France

On 04/02/2014 11:29 AM, dan...@redhat.com wrote:

Vdsm sync call April 1st 2014
=

- cpopen:
   - Toni: there's a versioning mismatch: the version in pypi is higher
 than the one on https://github.com/ficoos/cpopen
   - Saggi: there shouldn't be any code difference
   - Yaniv should sync the two.

https://github.com/ficoos/cpopen/pull/23 <- committed 1.3 tag
https://pypi.python.org/pypi?:action=display&name=cpopen&version=1.3 <- 
uploaded latest code


   - We use two options that are missing from Python3's Popen: umask and
 deathSignal.
 - Toni to re-send his Python3 port for cpopen, with tests running on
   Python3, too.
 - Saggi to accept it.
 - Infra team to suggest missing features to Python.




- fromani described his attempts of consolidating the two
   migration-monitoring threads into one. The motivation is a finer way
   of contolling the migration down time based on progress. Reducing
   thread numbers per se is not the main motivation.

- pep8 has changed. Again. Version 1.5.1 has even more draconic
   requirements. We can comply with them, or, include our version of
   pep8/pyflakes/pylint in our git repo. danken shudders at the thought
   of copying the code, but having a git sub-module is a reasonable
   compromise.
   - Infra team to take this task (unless someone else is faster)
   - Until that happens, one need to use pep8-1.4.6 or --ignore offending
 errors.

- We've been asked to kill the separate vdsm-devel mailing list, and
   join it into devel@ovirt.org. There's some resistence in the audience,
   so we'd do it softly.

   Next week, I'll have vdsm-devel members mass-subscribed to
   devel@ovirt. If you do NOT want to be subscribed, please send me a
   private request.

   Then, for several months, we'd see how it goes, and whether we drown
   in unrelated Engine chatter.

- We had a very (too) heated debate about ignoring failures of
   setDomainRegularRole() in http://gerrit.ovirt.org/24495/ and
   http://gerrit.ovirt.org/25424.

   The pain point is that relying on domain role (master/regular) is
   faulty by design. We cannot avoid the cases where a pool has more than
   one domain with a master role written in its metadata.

   One side argued that oVirt should be fixed to handle this unescapable
   truth, or at least enumerate the places where Vdsm and Engine, both
   current and old, depend on master role uniqueness.

   The other side argued that this is not a priority task, and that we
   should try to "garbage-collect" known-bad master roles as a courtesy
   to people digging into domain metadata, and as a means to lessen the
   problem until we kill the pool concept in the upcoming version.

   I hope that I present the debate fairly enough.

Dan.




--
Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel