Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago):
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
- How can the quality of the vdsm builds be increased? It is frustrating
to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms.
- How are the builds prepared? Is there a Jenkins job that prepares
"stable" rpms in addition to the nightly job? Or is this totally handcrafted?
- How can it be that the rpm spec differs between the 3.3 branch and
released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree...
Since this is VDSM related, adding vdsm-devel list to the discussion.
Thx and Regards Patrick
Hey Patrick,
For the pep8 issue, as mentioned you should check pep8 --version and use 1.4.6. If you use older version, just upgrade with python-pip (yum install python-pip , and then `pip-install install pep8 --upgrade`)
Second, try to follow http://www.ovirt.org/Vdsm_Developers , it specifies the repositories you need to set (which should solve and selinux-policy package you miss) and should be the same for ovirt-3.3. About the hostname issue, can you detail more about the issue .. I'm not familiar with such error
There are some differences between ovirt-3.3 branch and master in the requirements scope, each with specific reason. you should checkout ovirt-3.3 branch and not ovirt-3.3.0 for those tests
We are working on the quality and constantly trying to increase and improve the software. About the builds process you can talk with eedri for more details
Regards, Yaniv Bronhaim.
----- Original Message -----
From: "Sandro Bonazzola" sbonazzo@redhat.com To: "patrick hurrelmann" patrick.hurrelmann@lobster.de, "oVirt Mailing List" users@ovirt.org, "vdsm-devel" vdsm-devel@fedorahosted.org Sent: Tuesday, November 12, 2013 12:31:04 PM Subject: Re: [vdsm] [Users] Low quality of el6 vdsm rpms
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago):
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
- How can the quality of the vdsm builds be increased? It is frustrating
to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms.
- How are the builds prepared? Is there a Jenkins job that prepares
"stable" rpms in addition to the nightly job? Or is this totally handcrafted?
- How can it be that the rpm spec differs between the 3.3 branch and
released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree...
Since this is VDSM related, adding vdsm-devel list to the discussion.
Thx and Regards Patrick
-- 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
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised.
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago):
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
- How can the quality of the vdsm builds be increased? It is frustrating
to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms.
I suspect you are not interested in "excuses" for each of the failures, let us look forwards. My conclusions are: - Do not require non-yet-existing rpms. If we require a feature that is not yet in Fedora/Centos, we must wait. This is already in effect, see for example http://gerrit.ovirt.org/#/c/20248/ and http://gerrit.ovirt.org/19545
- There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days?
- Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
- How are the builds prepared? Is there a Jenkins job that prepares
"stable" rpms in addition to the nightly job? Or is this totally handcrafted?
- How can it be that the rpm spec differs between the 3.3 branch and
released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree...
Based on your reports, you are tracking the correct tree; but please describe which differences do you see (and between what releases exactly).
Regards, Dan.
On Tue, Nov 12, 2013 at 02:33:44PM +0000, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
- How can the quality of the vdsm builds be increased? It is frustrating
to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms.
I suspect you are not interested in "excuses" for each of the failures, let us look forwards. My conclusions are:
Do not require non-yet-existing rpms. If we require a feature that is not yet in Fedora/Centos, we must wait. This is already in effect, see for example http://gerrit.ovirt.org/#/c/20248/ and http://gerrit.ovirt.org/19545
There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days?
Is that based on repoclosure?
- Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
I think it was done using pip directly. I'd prefer to have a repo available for this on resources.ovirt.org through.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
Again, I'd prefer resources.ovirt.org but anything easily installable for the user is good.
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Sandro Bonazzola" sbonazzo@redhat.com, dcaro@redhat.com Cc: "vdsm-devel" vdsm-devel@fedorahosted.org, "oVirt Mailing List" users@ovirt.org Sent: Tuesday, November 12, 2013 4:33:44 PM Subject: Re: [Users] Low quality of el6 vdsm rpms
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised.
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago):
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
- How can the quality of the vdsm builds be increased? It is frustrating
to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms.
I suspect you are not interested in "excuses" for each of the failures, let us look forwards. My conclusions are:
Do not require non-yet-existing rpms. If we require a feature that is not yet in Fedora/Centos, we must wait. This is already in effect, see for example http://gerrit.ovirt.org/#/c/20248/ and http://gerrit.ovirt.org/19545
There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days?
it does run, but we can't enable it since it's still failing: http://jenkins.ovirt.org/job/vdsm_3.3_install_rpm_sanity_gerrit/label=fedora...
once that's fixed, the job will be enabled and run per patch.
Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
i tend to agree here with patrick on using non released pep8 packages, that are not available via rpms, but only via python-pip. the jenkins slaves were updated via pyhon-pip and not via yum upgrade.
- How are the builds prepared? Is there a Jenkins job that prepares
"stable" rpms in addition to the nightly job? Or is this totally handcrafted?
no jenkins job for stable builds. just nightly builds published from this job which build only rpms from master.
http://jenkins.ovirt.org/view/Packaging/job/vdsm_create_rpms/
- How can it be that the rpm spec differs between the 3.3 branch and
released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree...
Based on your reports, you are tracking the correct tree; but please describe which differences do you see (and between what releases exactly).
Regards, Dan. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Tue, Nov 12, 2013 at 10:31:24AM -0500, Eyal Edri wrote:
<snip>
- There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days?
it does run, but we can't enable it since it's still failing: http://jenkins.ovirt.org/job/vdsm_3.3_install_rpm_sanity_gerrit/label=fedora...
once that's fixed, the job will be enabled and run per patch.
Yaniv, any idea why we still have file /usr/lib64/python2.7/site-packages/cpopen/__init__.py from install of vdsm-python-cpopen-4.12.1-4.fc19.x86_64 conflicts with file from package python-cpopen-1.2.3-2.fc19.x86_64 ?
Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
i tend to agree here with patrick on using non released pep8 packages, that are not available via rpms, but only via python-pip. the jenkins slaves were updated via pyhon-pip and not via yum upgrade.
Eyal, I do not understand your opinion here... In any case, I've added http://danken.fedorapeople.org/python-pep8-1.4.5-2.el6.noarch.rpm if anyone find this unsigned unsupported hardly tested package useful.
Dan.
On Tue, Nov 12, 2013 at 04:41:53PM +0000, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 10:31:24AM -0500, Eyal Edri wrote:
<snip>
Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
i tend to agree here with patrick on using non released pep8 packages, that are not available via rpms, but only via python-pip. the jenkins slaves were updated via pyhon-pip and not via yum upgrade.
Eyal, I do not understand your opinion here... In any case, I've added http://danken.fedorapeople.org/python-pep8-1.4.5-2.el6.noarch.rpm if anyone find this unsigned unsupported hardly tested package useful.
A concerned user just asked me how did I build this. I just took the source from koji, http://kojipkgs.fedoraproject.org//packages/python-pep8/1.4.5/2.fc20/src/pyt... and built it on an el6 host with http://kojipkgs.fedoraproject.org//packages/python-sphinx/1.0.8/1.el6/noarch... installed.
Dan.
On 12.11.2013 15:33, Dan Kenigsberg wrote:
I suspect you are not interested in "excuses" for each of the failures, let us look forwards. My conclusions are:
Do not require non-yet-existing rpms. If we require a feature that is not yet in Fedora/Centos, we must wait. This is already in effect, see for example http://gerrit.ovirt.org/#/c/20248/ and http://gerrit.ovirt.org/19545
There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days?
Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
Yes, exactly. It wasn't my intention to blame anyone. I just wanted to express how hard it can be to test and show up some points for future work ;) I'm looking forward to the recent QA plans.
There has been an impressive overall improvement in the project over the last year, but there is still room for improvement. Thanks all.
Patrick
Hi Patrick,
On 11/12/2013 09:33 AM, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised.
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from?
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build.
We would appreciate if you could continue the tests with the new test build:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612
This last update includes the following patches: - The require hostname fix - upgrade-fix-v3ResetMetaVolSize-argument - lvm-Do-not-use-udev-cache-for-obtaining-device-list - Fix-ballooning-rules-for-computing-the-minimum-avail - Avoid-M2Crypto-races - spec-declare-we-provide-an-existing-python-cpopen - configuring-selinux-allowing-qemu-kvm-to-generate-co
@Mike, can you please update the testing candidate repo?
Thanks!
On 11/12/2013 03:51 PM, Douglas Schilling Landgraf wrote:
Hi Patrick,
On 11/12/2013 09:33 AM, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised.
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from?
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build.
We would appreciate if you could continue the tests with the new test build:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612
This last update includes the following patches:
- The require hostname fix
- upgrade-fix-v3ResetMetaVolSize-argument
- lvm-Do-not-use-udev-cache-for-obtaining-device-list
- Fix-ballooning-rules-for-computing-the-minimum-avail
- Avoid-M2Crypto-races
- spec-declare-we-provide-an-existing-python-cpopen
- configuring-selinux-allowing-qemu-kvm-to-generate-co
@Mike, can you please update the testing candidate repo?
Packages updated in beta repo
Thanks!
On Tue, Nov 12, 2013 at 03:51:36PM -0500, Douglas Schilling Landgraf wrote:
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build.
We would appreciate if you could continue the tests with the new test build:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612
This last update includes the following patches:
- The require hostname fix
(http://gerrit.ovirt.org/#/c/21194/ should have been sent to gerrit long ago, I suppose)
On 11/12/2013 04:52 PM, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 03:51:36PM -0500, Douglas Schilling Landgraf wrote:
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build.
We would appreciate if you could continue the tests with the new test build:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612
This last update includes the following patches:
- The require hostname fix
(http://gerrit.ovirt.org/#/c/21194/ should have been sent to gerrit long ago, I suppose)
Not really, actually, http://permalink.gmane.org/gmane.linux.redhat.fedora.extras.cvs/1127350 shouldn't be included in the previous build and it was during the spec merge from fedora spec, 4.12.0 and 4.13.0 for 3.3, my bad.
I did a new build on rawhide right now and the workaround is not needed anymore. I have back the original /bin/hostname for rawhide (as I did above).
We should be fine with vdsm-4.13.0-11 or higher.
On 12.11.2013 11:31, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
Will do. I just finished migrating an old 3.1 el6 installation to a fresh 3.3.1.
vdsm-devel@lists.fedorahosted.org